Closed metagn closed 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...
Issue is structured weird & I think different bindSym
and dynamicBindSym
is better but not bothering to make a new issue
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 normalbindSym
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:
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.