Proposed syntax could be potentially confusing to the JS community

[TejasQ]

Great proposal, @domenic! I think this as a syntax feature could definitely be unique and useful given the right circumstances.

I'm opening this issue because in light of some more recent JS tools and compile-to-JS languages, the syntax could be a little bit hard to adopt because it means different things around different tools, and less urgently, in different languages.

I find that this could make it a little harder to adopt: I would submit to you, I think the reason async/await came so naturally to some was because it had already been a language feature that did the same thing across other languages.

The {| |} heuristic of blöcks, however, translates quite broadly across the front-end landscape. For example, flow uses it for sealed object types in JS itself and does its type inference accordingly.

Additionally, the front-end world seems to be getting into ReasonML because of its idiomatic/intuitive interop with JavaScript. It too has a {| |} heuristic that translates to something different. While I understand that it may be a little too far out of the box to consider, it may still be worth considering what a blöck would look like inside of Reason code that is meant to dump JS as-is:

Js.log("this is reason");
let x = [%bs.raw {| 
  // Okay, this is JS now! Here comes my blöck!!
  const result = await worker({|
    const { fetch } = self;
    const res = fetch("people.json");
    const json = await res.json();
    return json[2].firstName;
  |});
|}];
Js.log(x ++ " back in reason land");

While Reason changing its JS-dump syntax to support blöcks better also makes a lot of sense (JS being the source of syntax-truth since it's the compile target), ultimately, my issue is birthed out of a concern for community: the JS community, of which the Flow community is a part, and separately, the Reason community which seems to be attracting JS community folks.

I merely suggest these nuances ought to be considered and discussed a bit more in order to maintain the welcoming nature of JS and its beautiful flexibility across the front-end landscape.

[Jessidhia]

More relevantly, this conflicts with the chosen syntax for another TC39 proposal: https://github.com/keithamus/proposal-object-freeze-seal-syntax#basic-sealing-of-an-object

This is something to be solved at the meetings I guess.

I assume the syntax was somewhat inspired by ruby, which does use | for marking blocks (well, their parameter list), but the character is already taken for a binary operator.

[domenic]

Thanks for the concern! I'm sure the syntax will be discussed, but for now it is what is being proposed, so I'd rather close this issue since it doesn't represent a spec bug, and isn't even really related to the JavaScript language, but instead to other languages.