Alternative syntax for <|

Russell Leggett russell.leggett at
Thu Nov 17 13:56:27 PST 2011

> It is also something that my proposed version of the class operator could
> do, because it always creates a function, and could desugar to the same
> semantics as the current function style.
> This may seem like a nit-pick, but I think it's not: any variant that sits
> at statement context in the grammar and has the form 'class C {...}' or
> 'class D extends B {...}' is not an expression using an operator. It's a
> class declaration.

Yes, I guess it would not be an operator at that point, but I had thought
that much the same way that function can be used as a declaration and an
expression, class could be used as a declaration and an operator. Perhaps
this is confusing or impossible. Seemed doable to me.

> 3. class hoisting, where all members of the class are available would
> require a formal class body instead of an expression, and probably some
> restrictions on the class body definition. I don't think any form of class
> proposed so far would allow this.
> Why not? Some proposals have either explicitly required (not allowed)
> this, or at least implied it.

Yes, sorry. I should have said "To my limited knowledge, ...". I had not
seen that as part of any proposal, but I haven't read them all or as
thoroughly as I could.

> Many proposals mirror function declarations vs. expressions by supporting
> all of class declarations (hoisted in some proposals as functions are, for
> the reason given above), named class expresssions (class name is usable in
> the class body but not head), and anonymous class expressions.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list