Expression 2: Add @feature directive for enabling backwards-uncompatible features, replace @strict with @feature edition1

[stepa2]

Wiremod updates have broken my chips fairly often, and it affected other players whom I gave my chips to.
I propose to disable new backwards-uncompatible changes unless they is enabled by @feature directive
and to stop adding new backwards-uncompatible changes enabled by @strict.

@feature syntax and functionality

"Features" are used to enable backwards-uncompatibe features.

Feature F may require other features A and B to function, in this case enabling F enables A and B.

# Enable features
@feature featureOne featureTwo

You can explicitly disable feature A. If other features F and G require it, they are disabled too.

@feature F G randomFeature
# Disables A, F and G. randomFeature does not require any disabled feature so it keep working.
@feature -A

Except features with "latest" in name, no feature should ever be changed in way that break existing code, except on language edition deprecation.

@feature latest requires all the features available now.
@feature disable_deprecated_latest disallow usage of everything deprecated

Language edition features

I suppose it would be impractical to list all the features your chip uses.
To simplify, I suggest to add "edition"/"milestone"/?? features.
They add nothing by their own, but they enable other features.

I suggest deprecation of @strict in favour of @feature edition1.
Future features plus edition1 will form @feature edition2, and so on.

Maybe some features will never be added to an edition.

Language edition deprecation

If technical debt is too big, older @editions and features they require may be removed completely.
It is supposed to be rare event.

Example features

• @feature disable_returnless_functions that disallows function number example() { print("no return") }
• @feature disable_function_redifinition that causes Expression 2: function predefinition is broken #2910
• @feature disable_deprecated_before_edition1 that disallows usage of anything deprecated before edition1
• @feature swap_logical_short_circuit_ops that makes || a short-circuiting operation and | a non-short-circuiting one.

[Denneisk]

Vurv will probably say to move this to discussions but I think his intent was to add a @version directive.

[AlexALX]

@version might be good solution so we can make old chips still work or something. but not sure what happens if you will remove later older version support...

[vurvdev]

As long as @strict isn't on, backwards compatibility should be guaranteed. The function returns thing was not good on my part and will be made into a warning.

Should never have to enable a directive to make an old E2 work because then that'd break all dupes.

[vurvdev]

@feature isn't gonna happen as that would just lead to a ton of things we have to maintain on or off. I would only add a @version or @edition directive that would only very rarely be incremented once a year at most, for large changes to E2 that would be very hard to implement with backwards compatibility, ie completely strictly typed objects (like array<T> instead of array type) would increment the edition, clientside e2 as well.

So first @edition would be @edition 2024 likely.

Also the simple answer: if you don't want to maintain your E2s, don't use @strict.

[vurvdev]

I had already planned to do this in order to enforce that users don't use things like string calls, function overrides, @persist, etc. on new versions.

[AlexALX]

well for me @strict mode in e2 looks as transforming "php into c#", with more flexibility we had (which allow to create pretty complex projects like my virtual PC), to more strict one which will make tons of limitations and need different workarounds if even possible to do same at all. but thats just imho.

[vurvdev]

If you want to compare @strict to something in an actual programming language, it's practically identical to JS/TS' "use strict"; directive.

Originally it was just to make functions error instead of breaking silently but I've recently been changing very obscure / weird behaviors different / removing them with the directive. I think it still fits same as JS since if you have "use strict"; you can't use the with construct for example.