domenic at domenicdenicola.com (2014-01-06T13:52:36.771Z)
early send ... again: That was to underline it is possible to define the constant twice, in two blocks, and use that later on as defined in one of those blocks. In current specs this is not possible. As Brendan mentioned about runtime checking for an "uninitialized" (not same as undefined), I would argue that undefined or declaration without assignment (which is === undefined) could be considered as const name reserved for the scope, first come, first serve, 'cause as developers might declare variables and forget to assign values, it should not be a specification concern how badly the developer can code. Linters are used for this purpose, highlighting uninitialized values. Last but not least, the first example Andreas wrote is a very handy piece of code: talking about the "inline try/catch expression" .. I wish it was already possible like that! That would surely simplify const definition, when try/catch is needed.
early send ... again: That was to underline it is possible to define the constant twice, in two blocks, and use that later on as defined in one of those blocks. In current specs this is not possible. As Brendan mentioned about runtime checking for an "uninitialized" (not same as undefined), I would argue that undefined or declaration without assignment (which is === undefined) could be considered as const name reserved for the scope, first come, first serve, 'cause as developers might declare variables and forget to assign values, it should not be a specification concern how badly the developer can code. Linters are used for this purpose, highlighting uninitialized values. Last but not least, the first example Andreas wrote is a very handy piece of code: talking about the "inline try/catch expression" .. I wish it was already possible like that! That would surely simplify const definition, when try/catch is needed. Best Regards On Fri, Dec 20, 2013 at 9:50 AM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote: > No, that was to underline it is possible to define this twice > > static int const NAME = > > > > On Fri, Dec 20, 2013 at 8:49 AM, J B <port25 at gmail.com> wrote: > >> Your C comparison was apples-to-oranges, #ifdef is evaluated at compile >> time. >> >> >> On Fri, Dec 20, 2013 at 8:32 AM, Andreas Rossberg <rossberg at google.com>wrote: >> >>> On 20 December 2013 04:05, Brendan Eich <brendan at mozilla.com> wrote: >>> > Andrea Giammarchi wrote: >>> >> >>> >> why is this not possible, giving the ability to understand through >>> typeof >>> >> if there is a value or not? >>> >> >>> >> ```javascript >>> >> // defined as const >>> >> // reserved in this scope >>> >> // but not assigned yet >>> >> const WHATEVER; >>> >> if (condition) { >>> >> // first come, first serves >>> >> WHATEVER = 123; >>> >> // that's it! const defined for the whole scope >>> >> // immutable from now on >>> >> } else { >>> >> WHATEVER = 456; >>> >> } >>> > >>> > >>> > Past JS2/ES4 designs have allowed this, but it requires definite >>> assignment >>> > analysis and use-before-defining-assignment error checking. >>> > >>> > In general, such checks can't be static in JS, so the language and VM >>> > complexity blow up a bit with runtime checking for an "uninitialized" >>> (not >>> > same as undefined) sentinel value that must be guarded against by a >>> read >>> > barrier where it can't be proven unnecessary. >>> > >>> > This is pretty obnoxious for implementors, not great for users either >>> (did I >>> > declare const IMPORTANT; and forget to assign IMPORTANT= in some >>> branch of >>> > control flow that my tests miss?). >>> > >>> > It's not in Harmony. We require an initialiser as part of the const >>> > declaration syntax. What you are doing here, by many measures, is >>> varying a >>> > variable from its default (undefined) value to a new value. >>> > >>> > If you want that variable to stop varying after, and you need it as a >>> global >>> > (window) object property anyway, use Object.defineProperty to make it >>> > non-writable. >>> > >>> > BTW, the last version your head post gave, >>> > >>> > const ES6_PROXY = function(){ >>> > >>> > try { >>> > new Proxy({},{}); >>> > return true; >>> > } catch(o_O) { >>> > return false; >>> > } >>> > }(); >>> >>> Of course, the problem here is hardly specific to feature detection, >>> or const, but simply an instance of the general annoyance induced by >>> the old-school statement/expression separation. What you'd really want >>> to write is something like >>> >>> const ES6_PROXY = try new Proxy({}, {}), true catch (_) false; >>> >>> For ES7 I would like to revive the do-expression proposal (hopefully >>> at the next meeting), so that one can at least approximate the above >>> with >>> >>> const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { >>> false } }; >>> >>> Of course, semantically the function is equivalent, and a fine >>> solution, if a bit verbose. >>> >>> /Andreas >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131220/5e40b2cb/attachment-0001.html>