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.giammar...@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 <por...@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 <rossb...@google.com>wrote:
>>
>>> On 20 December 2013 04:05, Brendan Eich <bren...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
