unexpected output for await somePromise\n.property

[Inve1951]

example:

await a b
.c

current output:

(await a(b).c)

expected output:

(await a(b)).c

[GeoffreyBooth]

await isn’t a function call, it’s a keyword like yield. Therefore chaining begins from the first token that can be chained off from, in your case a. This is also how yield behaves.

This is also how we would want it to behave, I would think. Consider a non-meaningless example:

do ->
  await S3.putObject(params).promise()
  .then (data) ->
    console.log data

(async function() {
  return (await S3.putObject(params).promise().then(function(data) {
    return console.log(data);
  }));
})();

[Inve1951]

here's the code that failed for me because of this:

@directoryList = do =>
  try list = await fs2.readdir @folder
  catch then return []
  filterAsync list, (fileOrFolder) =>
    await fs2.lstat _path.join @folder, fileOrFolder
    .isDirectory()

also in your example (i'm not familiar with that lib), wouldn't it be more likely to have

do ->
  data = await S3.putObject(params).promise()
  console.log data

or simply omitting await would still return a promise.

that aside, your output could be achieved with \ at the end of line 2.
unless i'm mistaken that's a perfect example for what the operator is ment for.

[GeoffreyBooth]

It’s this library. And sure, you’re probably right, your version would be more readable; I just already have code written using the chained promise style, so that’s what I copied. But my example illustrates what you’re proposing here: changing how chaining behaves when it follows await. My point is that the current output isn’t necessarily wrong, and some people might even prefer it. Therefore, changing it now would be an arbitrary breaking change, which we should avoid at all costs. The only breaking changes we should make before 3.0.0 should be to fix obvious bugs, where the current output is indefensibly wrong. The current output for chaining following await and yield doesn’t strike me as clearing that bar.

[Inve1951]

In case of yield that makes sense because (yield someValue) === undefined.

In case of await however it should be treated ambiguous and print/throw a (deprecation) warning. That is, until a potential change for CS3 as you mentioned.

I understand that a breaking change is undesired but current compilation is bug prone as it doesn't follow CS' whitespace-significance.

If no action is taken, then by the time CS3 might become a thing, current logic will be well known and likely won't be changed. Just like it was the case with ES6 in/of (that's an extreme example, i know).

[vendethiel]

In case of yield that makes sense because (yield someValue) === undefined.

That's not always the case tho.

[Inve1951]

Nice catch, wasn't aware of that feature.
So it can make sense for yield as well.

[GeoffreyBooth]

CS3 is a long way off. And I feel like if CS3 has a theme, it will be “clean up,” as in, clean up scope and chaining and other things that we didn’t change for CS2 because of concerns about breaking changes, but would like to change to clean up the language. But again, I don’t know when or if that will happen, or who is motivated to put in the work. I don’t think the wish list of stuff we’d like to refactor is long enough or important enough to motivate the small army we had pushing CS2 forward, at least not yet. There’s also something to be said for never making those changes, and avoiding a split like that happened between Python 2 and 3, which would weaken the CoffeeScript ecosystem even more than it already is.

All that said, should I close this? And we can start a wiki page for the CS3 wish list, and it could include this plus block scope and fixing the chaining syntax once and for all, among other items.

[Inve1951]

sounds good 👌

[Inve1951]

@GeoffreyBooth wrote a draft CS3 Wishlist