Final

[Simn]

This adds final as a keyword and allows using it in two places:

• As modifier to a method, like in Java.
• As replacement for var when declaring fields.

The semantics of the latter are as follows:

• static final vars have to be initialized immediately
• if a class has non-static final vars which are not initialized immediately, it requires a constructor which has to assign to all such fields
• static inline final works, but has the same semantics as static inline var
• visibility is orthogonal and not affected
• property syntax is not supported

Implementation details

I added a new var_access variant AccCtor which is used as the v_write value for non-static final vars. For static vars, we simply use AccNo. We internally add the @:final metadata to final fields (both vars and methods) in order to recognize final fields for the XML export. This also makes it automatically work with the already implemented @:final parts of the compiler.

Parsing is a bit funky: We can't parse final as a field modifier because it is also used for final x fields. We also have to consider that field modifiers may appear both before and after the final, which requires a call to parse_cf_rights twice.

[ncannasse]

When discussing it, we also suggested to allow { final x : Int } as a replacement for { var x(default,never) : Int }

[Simn]

Done

Note that there's a decision to be made there: Anonymous structures allow both class an structure notation, so when seeing the final we kind of have to make a choice in the parser. It works with structure notation only, so you can't do e.g. { final x : Int; var y : String; } (it wants comma instead of semicolon as the separator at that point).

[Gama11]

static inline final works, but has the same semantics as static inline var

Is there a good reason for allowing this then? It seems like this is just adds one more thing to worry about in code-style debates / one additional check in haxe-checkstyle. :)

[nadako]

What about simply always inlining static final when possible (same rules as current inline vars), which basically deprecates static inline var and reduces "cognitive burden" by a bit?

[RealyUniqueName]

Honestly i feel this final for vars is like abstract for decorators.
Why can't we just have const for vars? )

We already have (default,never) for static vars, which will now be duplicated with static final. And static inline var for real constants, which will also have a duplicate static inline final.

[Simn]

Is there a good reason for allowing this then? It seems like this is just adds one more thing to worry about in code-style debates / one additional check in haxe-checkstyle. :)

Technically, you'll have to worry about it anyway because if anything, it would be a typing error. That means that it's still valid syntax either way.

[Simn]

We already have (default,never) for static vars, which will now be duplicated with static final. And static inline var for real constants, which will also have a duplicate static inline final.

You would have the exact same situation with const or any other keyword.

[RealyUniqueName]

So let's think a bit more about reducing such duplications, not introducing them :)
It's a major version change anyway.

[Simn]

We could remove (default, never), but I don't really see a good reason to break people's code like that...

[RealyUniqueName]

Can we mark some syntax as deprecated and remove it in 4.1?

[wiggin77]

Will this eventually be expressed in target output? For example would "final s = new Something();" be marked as final in the Java target? This is important for generating thread safe code in cases where locks (constructors) are difficult.

[jgranick]

Can this can be overridden using @:hack?

[EricBishton]

It can be easily overridden using "search and replace." ;-)

[Simn]

Since final is just @:final for methods, @:hack should work accordingly. That's obviously not gonna work on targets which actually generate final natively though.

I feel like if you have to use @:hack, something went wrong somewhere...