Will `nimskull` embrace breaking changes?
ringabout opened this issue · comments
For instance, some features I want to see:
- identifier sensitive and
_can be used among identifier names for C interoperability - implement nim-lang/Nim#18422 (breaking change)
- remove some nasty or unused features (remove concepts or not; remove method (at least generic based method) and implement vtable instead)
Or nimskull will be compatible with Nim as far as possible?
Please see the readme specifically the direction section.
You'll see we're willing to make breaking changes; however, breaking for the sake of breaking or minor convenience isn't something we have the capacity to work through just yet.
If they're on mission then all good, otherwise they're presently a distraction. Specific areas where breaking changes are in fact very welcome are the currently on mission items. Chiefly, nkError related work.
We can consider further ones that aren't explicitly part of the current mission as long as they show excellent taste in reducing the over size of the language, standard library, tool chain, and/or bring about greater consistency in both the language and implementation.
The first two changes are to areas that aren't actively being thought about but I'm curious which unused features you'd consider removing?
Allowing identifiers starts with underscore was discussed:
nim-lang/RFCs#428
remove some nasty or unused features
such as drnim,
something like proc find*(buf: cstring, pattern: Regex, matches: var openArray[string], start = 0, bufSize: int),
replace generic threads procs with low level threads procs wrapper.
dispatching by procs parameter names (proc hello(a: int) and proc hello(b: int)),
remove owned
nimsuggest could also be deprecated in the future in favor of much more widely used LSP protocol that is adopted by virtually any modern text editor there is.
Probably can kill TRM macros since there is hardly any use for them, even if they weren't that buggy.
Maybe move some stdlib modules out into https://github.com/disruptek/dist or deprecate them entirely.
Just my opinion, but the problem with term-rewriting macros is that they are just way too powerful and become essentially magical in use. It's a tough call.
Just my opinion, but the problem with term-rewriting macros is that they are just way too powerful and become essentially magical in use. It's a tough call.
The amount of things that have to not only work well but be incredible transparent and easy to debug would put term rewriting macros incredibly out of reach for a good long while. Which means we can't really learn of it's a good idea or not.
I'll leave this issue open for a day or two more, I think this should turn into some breaking changes guidance doc, that should answer the question:
"Under what circumstances is a breaking change acceptable?"
make sense!