Allow (some) keywords as field names / var names

[kevinresol]

Since field access is pretty much predictable, I think it should be ok.

The main problem lies in import MyClass.* where the field access becomes unpredictable (and this becomes the same case as var names). So keywords that can act as the beginning of an expression, such as var, function, controls keywords (e.g. if, switch, while...), should still be forbidden.

So I think some of the possible candidates are:

obj.default();
obj.enum;
obj.in();
obj.macro();

etc...

[nadako]

I guess this is a question of context-specific keywords which should be possible, and even useful, but not I'm sure what long-term consequences that's gonna have. (e.g. if we allow enum as an identifier, i'll be harder to introduce local enum type declaration if we'll ever want it).

[kevinresol]

In that case, what if we only allow field access, so leaving import * and var as-is? In other words, MyClass.default(...) would work, while import MyClass.* + default(...) would result in the usual parse error.

Btw, i want to mention that among all keywords, I think the most "wanted" one would be default and in, which I encounter most in extern APIs and external data (e.g. json)

[Simn]

This is not worth it. It would complicate the parser for no real benefit other than a mildly nicer to read field access in some rare cases. There's already some inconsistency with the macro and extern keywords being allowed in package names, but that doesn't mean that we have to make it worse.

I'm pretty sure this would also annoy many IDEs.

[kevinresol]

My concrete proposal summary:

Location	Keywords allowed?	Remarks
Member function/var	Yes	Must be accessed through this.keyword, inst.keyword or MyClass.keyword. import MyClass.* will not expose the function/var`
Local function/var	No
Package name	Yes	Except that keywords cannot serve as root package, i.e. package haxe.macro is allowed, while package macro.whatever is not.