Brendan Eich brendan at mozilla.org
Mon Aug 25 15:38:20 PDT 2008

On Aug 25, 2008, at 3:00 PM, Ingvar von Schoultz wrote:

> ...we'll have to write something like this?
>      const
>      {   DatabaseName,
>          DisplayCount,
>          ... Ten more ...
>      } =
>      Debugging ?
>      {   DatabaseName: "TestDatabase",
>          DisplayCount: 5,
>          ... Ten more ...
>      }
>      :
>      {   DatabaseName: "RealDatabase",
>          DisplayCount: 15,
>          ... Ten more ...
>      };
> Very often conditionals aren't that simple. It'll get ugly. The
> new awkwardness does makes sense in big projects, but only there.

Another way of looking at this is to say that const should be write  
once, not necessarily initialized in the declaration. Then you could  

const DatabaseName, DisplayCount, /* ... ten more ... */;
if (Debugging) {
     DatabaseName = ...;
} else {

This was ES4's const. At the Oslo meeting there was strong opposition  
to write-once. The reasons were not clear to me (could be my fault).

Here you show a reason for write-once. The alternatives are  
destructuring from a ternary (as you showed), falling back on var  
(losing), or inventing some super-const binding form that escapes its  
block (not in the cards).

>> let
>> blocks and let expressions do not have solid support in TC39.
> I have no opinion on whether let blocks and let expressions
> are useful, but you could make them very cheap by dropping the
> intricacies that make let(x=x){} refer to two different x'es:
>      let (a = x) {...} desugars to {let a = x; ...}

If by "cheap" you mean easy to implement, there would be a savings to  
compiler costs, but not at runtime.

>      let (a = x) a; desugars to {let a = x; a;}

Sorry, no: the latter is not an expression, the former is (if you  
remove the ; at the end).

> As a bonus everyone will rejoice at the lessened cognitive burden
> of intricacies.

But then why have the let block form at all, since let declarations  
are sweet enough.

The case for let expressions remains even if you eliminate the let  
binding rule, since they are expressions. You'd have to invent  
generalized BCPL- or Algol-68-like expression language support, which  
is also not in the cards (I mentioned the idea briefly in Oslo, more  
as a joke or an aside).

> Of course Schemers will find a let with these semantics confusing.
> Clearly it needs a different name. How about... "local"? :-D

Sorry, no; please stop nagging.


More information about the Es-discuss mailing list