Open hydroper opened 1 year ago
I think supporting a multitude of styles from various languages in Haxe will mostly create confusion, but more importantly create obstacles for when we do want to add new syntax with new semantics, e.g. the *
for a type param could mean a whole bunch of things other than Dynamic
that might have distinct use cases.
I see some value in supporting ECMAScript syntax. The advantages of using standardized syntax are quite obvious and Haxe did start out being advertised ECMAScript dialect. It diverged from its heritage for a whole bunch of good reasons, but there's been a whole lot of parallel evolution, where there's little value in Haxe having a different syntax than ES/TS do. If anything, I think a separate frontend for an ECMAScript aligned syntax would actually be relatively useful, but I don't see the work involved (especially with IDE support) paying off.
Haxe has some subtle differences from TypeScript and EcmaScript 4 (inexistent) syntax.
type
rather than a reserved wordtypedef
. EcmaScript 4 too was going to usetype
(whether in ES4 it was going to be contextual or not I don't remember, though the EcmaScript 4 reference interpreter is available in archive.org).Array<T>
asT[]
. In EcmaScript 4 you would be able to expressArray.<T>
as[T]
. To me, it seems like the EcmaScript 4 syntax for specifying array types in brackets is cryptic and readable at the same time.any
. In EcmaScript 4, it's written*
.More specifically, in these languages,
type
is reserved when it's followed or preceded by another identifier or reserved word, so it doesn't break compatibility.Here's a Haxe version:
Here's an EcmaScript 4 version:
I think it'd be interesting if Haxe supported the same ES4 syntax for clarity, considering it'd not break compatibility. It doesn't break macros, does it? After all, Haxe was inspired by ES4.
Another thing I didn't mention is that the decorator syntax of ES4 used brackets, not
@:
.