RFC for symbol alias for https://github.com/nim-lang/Nim/pull/11992 #235
Conversation
| composable iterators, which allows define lazy functional programming primitives (eager `toSeq` and lazy `map/filter/join` etc; which can have speed benefit compared to `sequtils`); the resulting code is quite nice and compact, see `tlambda_iterators.nim` which uses library `lambdaIter` that builds on top of `lambda`; it allows defining primitives that work regardless we're passing a value (`@[1,2,3]`) or a lazy iterate (eg `iota(3)`) | ||
|
|
||
| ## Motivation 5: this fixes or closes a lot of issues | ||
| see a sample here: https://github.com/nim-lang/Nim/pull/11992 |
There was a problem hiding this comment.
It's logically impossible that a feature addition fixes existing bugs. What do you really mean? That the patch also happens to fix existing compiler bugs? That the new feature allows for new workarounds?
There was a problem hiding this comment.
the distinction between bugs and feature requests is by definition a gray area, and some github issues are reducible to feature requests so there's no contradiction.
Anything I listed in nim-lang/Nim#11992 as closable should be closable with that PR (because it'd make no sense keeping the issue opened past that); but of course we can debate that list 1 by 1.
- in some cases because this PR provides a good enough solution (I wouldn't call it workaroud unless there's some kind of drawback involved)
- in other cases it's a proper fix, eg:
- Cannot pass inline iterator to inline iterator Nim#4516 "it should be possible to pass an inline iterator to another inline iterator." (OP doesn't require a specific syntax)
- symbols of no argument templates can't be passed to macros Nim#11870 "symbols of no argument templates can't be passed to macros" => OP doesn't impose a specific syntax; this PR proposes a general fix for that so it fixes this issue as well
- type inference with lambdas doesn't work (requires explicit types) Nim#7435 "type inference with lambdas doesn't work (requires explicit types)"
likewise, that issue doesn't care whether it'ssugar.=>or something else, and this PR solves this via~>(with plenty of tests) - alias declarations Nim#7090 "alias declarations" (was marked as closed but it should not have been closed for reasons explained in this PR+RFC; this PR properly fixes it)
and IIRC the PR has tests for all issues I intend to close with this PR.
|
merging but happy to address more comments |
No description provided.