-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add switch, warning, and bind
support for new generic injection behavior
#23102
Conversation
…avior refs nim-lang#23091, especially post merge comments
842cc37
to
467e02e
Compare
the global flag solves the immediate problem but I think this is something that we need to come back to - also because it doesn't offer a way out really - ie when we want to make this feature "official", we will still need a "local" way to mark an individual symbol as ok-to-lookup-again |
You mean it shouldn't be the default? It's the expected behavior in non-generic code. I thought about Edit: Also as said in the other comments, |
If this had been the behavior from the start, it should certainly have been default. I'm not sure however how wide the impact is so we're in a bit of a bind.
Yes - though consider the results case: I want to mark the Now as I'm writing the above, I realize that if I annotate Result, users of Result will not know that their code changed semantics. Messy. |
I'll play around with the flag and see where it leads. Much appreciated. |
We could always do something like: let x = f().valueOr:
return (error {.inject.}) from a technical perspective, I just wonder which way would lead to the least surprise to the user. The case where the user needs let x = f().valueOr:
{.push experimental: "genericsOpenSym".}
return error
{.pop.} is not great but at least "experimental" implies that those lines are temporary. I also just realized that any switch we add would also not work on older versions anyway, which would be a problem for most people. I don't know a workaround better than: const error = ()
let x = f().valueOr:
return error Maybe the least we could do is suggest this. |
I have this beautiful rewriting hack available for old versions which I'm considering: arnetheduck/nim-results#35 - for that, it would be nice to have something like Also, I just saw |
Sorry, that was a proposed syntax, I meant it would be easy to implement but obscure/ugly.
It's whenever new symbols are introduced in local scope that were not known during the early analysis of the generic proc, which can only really be achieved by templates and macros. |
Thanks for your hard work on this PR! Hint: mm: orc; opt: speed; options: -d:release |
backportable? how far? |
…avior (#23102) refs #23091, especially post merge comments Unsure if `experimental` and `bind` are the perfect constructs to use but they seem to get the job done here. Symbol nodes do not get marked `nfOpenSym` if the `bind` statement is used for their symbol, and `nfOpenSym` nodes do not get replaced by new local symbols if the experimental switch is not enabled in the local context (meaning it also works with `push experimental`). However this incurs a warning as the fact that the node is marked `nfOpenSym` means we did not `bind` it, so we might want to do that or turn on the experimental switch if we didn't intend to bind it. The experimental switch name is arbitrary and could be changed. --------- Co-authored-by: Andreas Rumpf <[email protected]> (cherry picked from commit 4b1a841)
refs #23873 (comment), fixes #23386, fixes #23385, supersedes #23572 Turns the `nfOpenSym` node flag implemented in #23091 and extended in #23102 and #23873, into a node kind `nkOpenSym` that forms a unary node containing either `nkSym` or `nkOpenSymChoice`. Since this affects macros working on generic proc AST, the node kind is now only generated when the experimental switch `genericsOpenSym` is enabled, and a new node flag `nfDisabledOpenSym` is set to the `nkSym` or `nkOpenSymChoice` when the switch is not enabled so that we can give a warning. Now that the experimental switch has more reasonable semantics, we define `nimHasGenericsOpenSym2`.
refs #23091, especially post merge comments
Unsure if
experimental
andbind
are the perfect constructs to use but they seem to get the job done here. Symbol nodes do not get markednfOpenSym
if thebind
statement is used for their symbol, andnfOpenSym
nodes do not get replaced by new local symbols if the experimental switch is not enabled in the local context (meaning it also works withpush experimental
). However this incurs a warning as the fact that the node is markednfOpenSym
means we did notbind
it, so we might want to do that or turn on the experimental switch if we didn't intend to bind it.The experimental switch name is arbitrary and could be changed.