-
Notifications
You must be signed in to change notification settings - Fork 0
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
ident literals not subject to style insensitivity, for interop: proc $foo__bar
()
#806
Comments
If this change is made, I would also like to suggest reconsider the rule about starting and ending with I did not see a reason not to (more than "Meh, looks bad" and similar).
|
the special syntax i propose here would allow this: proc `$_foo_`() or did you mean to support this? proc _foo_() i tried to suggest this, but see backlash in nim-lang#8807 you might argue that
Ideally there'd be a simpler escape hatch with less extra noise-characters, eg: proc !_foo_() (feel free to suggest ideas that have a chance of working) but I don't know which would work well (without introducing breaking changes etc)
i don't think so because it'd create ambiguities + amount of breaking changes it'd introduce:
hence a special syntax is needed IMO design goals:
type A = `$std::vector`[int]
|
I mean double underscore at the start of the identifier name and double underscore at the end of the identifier name. Based on experience doing https://github.com/juancarlospaco/cpython |
but if you allow double btw, my proposal for proc !__dict__()
let b = a.!__dict__ # is it `.!` operator or `.` followed by `!__dict__` ? => ambiguous with this RFC you'd have no ambiguity, but it's ugly: proc `$__dict__`()
let b = a.`$__dict__` with nim-lang#8807, you'd have: proc __dict__()
let b = a.__dict__ and everything would "just work", no breaking change, no ambiguity, since these syntax (start/trail underscore) are currently forbidden. |
btw, i was unaware of https://github.com/juancarlospaco/cpython, looks super interesting (but see questions i posted there) |
Works for me...
I like the RFC. |
Example
note
this fits well with the special syntax we added for user defined literals:
links
The text was updated successfully, but these errors were encountered: