new keywords

Since we’re breaking (binary, at least) compatibility in the next release, I think it’s a good time to consider the list of keywords we have in the language, and whether we should do a minor break to source compatibility to add new keywords.

So the question is: what syntax do we have (or propose) that would be improved by the addition of a keyword?

The only one that comes to mind immediately for me is the syntax for destructuring statements (discussed here #6446). By adding a new keyword (values, perhaps), we could “fix” the syntax for a destructuring statement, resulting in:

values (key -> item = 1->2,
       [first, *rest] = 1..10;

And:

values (Integer key -> Integer item = 1->2,
       [Integer first, Integer* rest] = 1..10);

Is there any other language feature like that?

The second thing that comes to mind is async/await. Are we going to need new keywords for that? Should we reserve them now?

(Please let’s not turn this thread into a long re-discussion of #6446. The topic is keywords.)

[zamfofex]

I tend to dislike writing functions with (a lot of) side effects, but it seems other people like them. Either way, I think reserving a yield keyword might not be the worst idea, just in case.

#3418, #4391

[zamfofex]

@IamSungod

This era requires fine-grained massive concurrency.

I thoroughly agree (in fact, I was thinking about it just the other day), so I’ve been reading about Kotlin coroutines for the last couple minutes, and it doesn’t seem to me as if runBlocking is implementable in JavaScript (unless every generated JS function is marked as async).

The async and launch functions (which can only be called from suspend functions) do basically the same as async does in JavaScript.

So I don’t really see how this is more expressive or better than JavaScript’s concurrency using async and await. Without runBlocking, it seems to me like it’s just merely defined by less generic features, as it is a hardspecced feature, and not just syntactic sugar, even though it’s conceptually the same.

I would just have an asynchronous annotation that makes the function return a promise and an await expression which waits for a promise to be finished that can only be used inside asynchronous functions.

As a demonstration, here is the port from Kotlin to JavaScript of the program used as an example in the page I’ve linked:

let range = (s, e)=>({[Symbol.iterator]: function*() {for(let i = s; i <= e; i++) yield i;}});
let hold = s => new Promise(d=>setTimeout(d, s*1000));
let workload = async n => ((await hold(3)), n);
let sum = 0;
for(let i of [...range(0, 100000)].map(workload))
{
    sum += (await i);
}
console.log(sum);