nim-lang / RFCs

A repository for your Nim proposals.
135 stars 26 forks source link

Experimental vs opt-in language features #485

Closed metagn closed 1 year ago

metagn commented 1 year ago

Some of the remaining experimental features seem to be stable, however they are still experimental, maybe due to the experimental switch making the feature opt-in, which may be beneficial for things like performance. Calling stable features like these experimental is misleading, and they should be made independent of the experimental switch.

Another thing to consider is that we probably do not want regular compiler options to change the language at fundamental levels, because of the configuration dependencies it creates for source code.

These features are:

dynamicBindSym

Enabling dynamicBindSym turns all bindSym calls into "callbacks" of sort that call the actual bindSym implementation. From what I understand this impacts performance of bindSym.

A compromise that makes this feature opt-in without requiring an experimental switch is defining another proc dynamicBindSym on top of the normal bindSym that performs the possibly less performant behavior. This has been implemented in https://github.com/nim-lang/Nim/pull/20125.

As mentioned in that PR this feature does have a relevant bug, https://github.com/nim-lang/Nim/issues/11496. However it seems to be easy to workaround, and having another symbol for it than bindSym just makes this bug easier to manage.

Old:

## unicodeOperators (made default now) This feature seems to be stable and shouldn't break basically any existing code. Does it impact performance? From what I understand, it only kicks in when the specific surrogate characters that the set of predefined unicode operators start with are encountered. To me this seems like it would have a negligible impact on performance as unicode characters, let alone the unicode characters that start with those specific surrogate characters, are rare in Nim code. Performance is the only concern I can think of for why it should be opt-in. If someone more informed can confirm that making it default shouldn't be a problem, then I propose it should be made default.

More may be added/commented later as they stabilize. For example features like callOperator/dotOperators, compiletimeFFI may become more stable, but there is still the discussion of making them into compile options, or enabled in pragma blocks/push pragma context in the case of call/dot operators.

Araq commented 1 year ago

Opt-in language features are worse than experimental or obsolete features. Every opt-in language features creates a language dialect. The fate of "dynamicBindSym" is tied to the compilation pipeline and whether alternative "eval at compile-time" implementations can easily support it...

metagn commented 1 year ago

Issue is structured weird & I think different bindSym and dynamicBindSym is better but not bothering to make a new issue