Best syntax is {> .....}

[pvider]

It is very short: {>let x = 100; x * x} vs do{let x = 100; x * x} It is unambigous, do is not overloaded: {>do f(); while (x);} vs do do f(); while (x); It {> part resembles fat arrows => which implicitly return.

[soulofmischief]

+1 for not overloading do

Not sure if overloading > is a good idea considering that in JSX <Component>{> 'Hello' }</Component> seems visually unbalanced.

I'm also unsure of how overloading > might affect existing JSX parsers.

[rosyatrandom]

How about

let x = {| /* blah */ |}

[ljharb]

@rosyatrandom that conflicts conceptually with the flow syntax for sealed objects/types; and may conflict with a proposal for frozen object syntax.

[nicolo-ribaudo]

that conflicts conceptually with the flow syntax for sealed objects/types

This shouldn't be a problem, since it is only allowed in type contexts and not in expression contexts.

[ljharb]

That’s why i said “conceptually” - it creates two meanings for the syntax.

[claudepache]

Experience shows that, surprisingly, two meanings for a same syntax do not generate conceptual conflicts if they are used in different contexts. I’m thinking of code block vs. object literal, or decimal separator vs. property acccessor, or division vs. regex literal, or...

Le 22 juin 2019 à 03:10, Jordan Harband notifications@github.com a écrit :

That’s why i said “conceptually” - it creates two meanings for the syntax.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ljharb]

Those imo are all examples of legacy confusion best avoided in new constructs :-)

[rosyatrandom]

In all honesty, I just wish we could use more of these: http://xahlee.info/comp/unicode_matching_brackets.html

Obviously, they aren't on a standard keyboard, and I know you really don't want to add too much symbols, but can you imagine the luxury of having more distinct brackets for things?

I would limit it to 1 or 2 from:

• ones that are used by standard convention in other languages: « » 「 」 〈 〉 《 》 【 】 〔 〕 ⦗ ⦘ or
• the mathematical ones: ⟦ ⟧ ⟨ ⟩ ⟪ ⟫ ⟮ ⟯ ⟬ ⟭ ⌈ ⌉ ⌊ ⌋ ⦇ ⦈ ⦉ ⦊

Imagine no collision between code blocks and objects! Imagine... well, there's a lot of possibilities here..

On Sat, 22 Jun 2019, 02:49 Jordan Harband, notifications@github.com wrote:

Those imo are all examples of legacy confusion best avoided in new constructs :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-do-expressions/issues/32?email_source=notifications&email_token=ABHSXAJLZJVBVSESMLEUNS3P3WAMLA5CNFSM4FVAOAH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJ5QNI#issuecomment-504617013, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHSXAL67ZLNL2OJ7D36G2LP3WAMLANCNFSM4FVAOAHQ .

[ghost]

@rosyatrandom Don't do that.

1. Would you like to hear a ShiftJIS joke and a GB18030 joke?
2. I don't want switch IME when coding, I believe you won't either.

[hax]

Using unicode brackets is a GREAT idea. Today I happened have an interview, the candidate just waste several minutes because she entered if（ instead of if (. Such accidents are very common in east asian programmers' life, now it's time to let you western to enjoy it 🤪

[hax]

I heard that there is a syntax option like let x2 = (let x = 100; x * x) (just use parens) but can't find related issue. Consider this issue is also discussing syntax alternatives, pls allow me to temporarily leave comment here.

And it seems the main concern of the original issue is overloading do, maybe we could also consider other keyword. For example, let x2 = eval { let x=100; x*x }, especially if we keep the behavior consistent with current let x2 = eval("let x=100; x*x").

(Note, the readme said "I have several alternatives I intend to explore here" but I can't find the list in the repo.)

[ghost]

maybe we could also consider other keyword

+1, there's not so much symbols left in ASCII

eval

May cause some confusing, when I say eval, maybe I mean that old function, maybe I mean the brand new syntax here. Choose a new word is better. ( Maybe run or exec? )

[hax]

when I say eval, maybe I mean that old function, maybe I mean the brand new syntax here.

@studentmain Yeah, instead of overloading do, this alternative choose overloading eval 😂 . (And eval has already been overloaded with two different thing: "direct eval" vs "indirect eval".)

But consider import (static import vs dynamic import) and current do (do-while loop vs do expression) as precedent , we could give it a unambiguous name, like "eval keyword" or "static eval".

[Killea]

what about let a = {{ let b = 0 ; b+=1; }}?

[kosich]

Will not {{ … }} be confused with (x, y) => {{ x, y }}? Which, surely, is nonsense nowhere to be found, but is an allowed syntax atm. Is it a problem?

I also kinda expect let a = {…} to be related to object/tuple/set/whatever inline instance creation.

[guiga-zalu]

@rosyatrandom In all honesty, I just wish we could use more of these: http://xahlee.info/comp/unicode_matching_brackets.html

• ones that are used by standard convention in other languages:
  • « » 「 」 〈 〉 《 》 【 】 〔 〕 ⦗ ⦘
• the mathematical ones:
  • ⟦ ⟧ ⟨ ⟩ ⟪ ⟫ ⟮ ⟯ ⟬ ⟭ ⌈ ⌉ ⌊ ⌋ ⦇ ⦈ ⦉ ⦊

What about a construction based on these, made of ASCII characters?

• << ... >>, |[ ... ]|, |( ... )| ...
• [[ ... ]], <[ ... ]>, [< ... >], [> ... <] ...

For whoever uses fonts with ligatures, these would seem as totally new, and for the ones who don't use, too!

[Explosion-Scratch]

+1 for not overloading do

Not sure if overloading > is a good idea considering that in JSX <Component>{> 'Hello' }</Component> seems visually unbalanced.

I'm also unsure of how overloading > might affect existing JSX parsers.

Yes, what about handlebars:

<div>{{> partial}}</div>

[aspirisen]

Just curious, why not to use |exp| to define expression block, for example

doAction(cond => | if (cond === 'one') 1 else if (cond === 'two') 2 else 0 |)

const x = |
  if (cond === 'one') 
    1
  else if (cond === 'two') 
    2
  else 
    0
|

So everything inside || is treated as an expression

[coolCucumber-cat]

As for brackets, the only one that don't conflict and also makes sense would be |{}|. It still uses curly brackets and the only conflict would be with ||.

What about some kind of prefix? Like @, which is common on keyboards and has no conflicts, ! just kinda makes sense somehow, \ has no conflicts and could be like how () coerces the parser to interpret things in a certain way, | , / etc.

What about taking inspiration from arrow functions? You could think of => meaning a code block will follow (or a shorthand return, not important right now), maybe it could be reused in place of the do keyword, for example const exp = => { 123 }. Or some variation of it, like :>, ->, <= etc.