Reserve keywords for Haxe 4.0

[Simn]

Even if we don't implement them yet, we should reserve them already:

• overload
• something like async/await?
• operator
• protected

[RealyUniqueName]

something like async/await?

We don't need these If we want to have only generic coroutine implementation without the need to teach the compiler the semantics of specific coroutine types (like async/await, generators etc).
We need something like suspend (for functions which suspend coroutines) and coroutine (for functions which get transformed into state machines).

[RealyUniqueName]

Also is :)

[nadako]

We need something like suspend (for functions which suspend coroutines) and coroutine (for functions which get transformed into state machines).

IIRC in my (kotlin's :)) original proposal, only one keyword is needed, e.g. suspend is both suspending and transformed.

[Simn]

Does anyone have feelings about a replacement for @:op?

[nadako]

Does anyone have feelings about a replacement for @:op?

Ideally we would have something like function +(a, b), but that means we'd have to generate function names for run-time based on the operator name (and arg types for overloading). I'd be in favor of that anyway, but it requires a lot of design.

[Simn]

I'm not worried about name mangling because we have to sort that out for overload anyway.

I'm not sure about unops because you want to distinguish ++a and a++.

[nadako]

I'm not sure about unops because you want to distinguish ++a and a++.

Right, don't really want to go the C++ way and have a marker argument... Hmm

[back2dos]

Does anyone have feelings about a replacement for @:op?

Unless you're planning to make it from static function ... I think @:op is just fine. It's short and pretty descriptive.

I think aggressively reserving relatively common keywords would be good in that it'll allow adding their syntax without breaking changes (macros aside). It should be combined with a plan for allowing them in field names to reflect native APIs. My personal favorite would be to allow all keywords to be field names (kind of like it's done with macro).

[Justinfront]

@:op == operation

[ncannasse]

Does anyone have feelings about a replacement for @:op?

In order to give proper syntax for overloaded operators, I think it would require a new keyword operator , then:

function operator(+)( a, b ) {
}

• unary - vs opneg can be differentiated based on number of arguments
• there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

There's also the problem of generating a valid function name. the parser could put the operation in @:op like it used to be and set the function name as empty "" , then the compiler would generate the name based on a common name "add" "sub" etc. + eventual numbering/suffixes if several declarations with different types.

[RealyUniqueName]

there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

That limits the possibilities of operator overloading. E.g. prefix and postfix ! carry completely different semantics.

[dpomier]

there's the problem of unop prefix vs suffix (++a vs a++) but maybe the problem is that we should only define only one operator(++) and have the compiler return the value of a before or after the operation.

Maybe the keyword operator could be operation to allow something like this?:

function operation(a+b)( a, b ) {
}
function operation(++a)( a ) {
}

[Simn]

I don't really see a problem with allowing an identifier for unops:

• operator(++a) for prefix
• operator(a++) for postfix
• operator(++) for both

Do you think it's strange that it would be allowed for unops but not for binops? I find that fair... and I don't want to allow it for binops because then we have multiple syntaxes that mean the same thing. I also don't want to require it for binops because that seems pointless...

[ncannasse]

Well we would only need an identifier to differentiate ++a from a++ , and I fail to see a compelling case when I want a++ it to do something different than { var tmp = a; ++a; tmp; }

[ncannasse]

@RealyUniqueName ah I forgot about postfix custom operators, maybe then we should follow @Simn proposal, would still not allow them for binops

[RealyUniqueName]

You never know the user's domain specifics :)
I think making this feature as flexible as possible is better than applying synthetic restrictions. Especially taking into account current implementation.
Also, we have @:commutative for the cases when the order is not important.

[Simn]

Right, @:commutative... that makes me think we should allow identifiers for binops after all and follow the same rules like we do for unops:

• operator(a+b) for non-commutative
• operator(+) for commutative

That aligns quite nicely: If it's just the operator, we get the widest possible interpretation. And by adding identifiers you can restrict it to prefix or postfix for unops, and non-commutative for binops. It's also matches our current approach for @:op because we require the identifiers there and default to non-commutative.

Anyway, I'm gonna reserve operator and overload for now and we'll have to see about the asynchronous thing.

[Simn]

It should be combined with a plan for allowing them in field names to reflect native APIs. My personal favorite would be to allow all keywords to be field names (kind of like it's done with macro).

Yes we should discuss this. I certainly don't want to encourage something like this, but I also don't want to make it unnecessarily difficult to match extern APIs.

A problem is that it's easy to support something.public, but public.something is a different case as far as the parser is concerned.

Also, I can already hear @Gama11 cry in the distance if this is to be properly syntax-highlighted.

[frabbit]

I actually like to give operators descriptive names, the generated code is cleaner and you have a name to talk / search about etc. It's fine to have operators but a well named alias is a good thing imho.

[Simn]

Might want to reserve protected, just in case.

[RealyUniqueName]

As for coroutines, I've written some considerations here: nadako/haxe-coroutines#13

[ncannasse]

I'm not sure about protected given we are very unlikely to introduce it (our private is already protected in Java), and we wouldn't want to change the whole definition.

Ok for async/await/operator, although I hate keywords :)

[Simn]

Given that the only implementation somebody worked on doesn't use async/await keywords, I'll not reserve them for Haxe 4.