ident literals not subject to style insensitivity, for interop: proc `$foo__bar`()

[timotheecour]

Example

{.push: importc.}
proc `$a::b`()
proc `$ i can have space and not use stropping`()
proc `$_foo_`()
proc `$foo__bar`()
proc `$foo_bar`()
proc `$fooBar`() # different from proc `$foo_bar`()

note

this fits well with the special syntax we added for user defined literals:

proc `'big`(a: string): int

links

• [TODO] small amendment to style insensitivity: leading/trailing underscore disables style insensitivity; use case: avoid symbol clashing for FFI / interop · Issue #8807 · nim-lang/Nim
• https://discord.com/channels/371759389889003530/768367394547957761/880905547992412251

[juancarlospaco]

If this change is made, I would also like to suggest reconsider the rule about starting and ending with _,
for improving easy interoperability with Python, Python uses __foo__ a lot,
and a lot of code in the wild is Python or compatible,
whether we like it or not is one of the most used programming languages,
if we can get even 1% of Python people interested in Nim it would be a massive growth for Nim.

I did not see a reason not to (more than "Meh, looks bad" and similar).
I dont care using an experimental flag --experimental: something.
It is not to became the default nor recommended style, but should be doable for Python interop/ffi.

• Can Stropping be "extended" to allow such styles without adding new syntaxes ?.

[timotheecour]

If this change is made, I would also like to suggest reconsider the rule about starting and ending with _,

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 $_foo_ is a bit ugly to type, but hopefully that'd be rarely used, but can save your life in situations where you need this; 2 cases:

• automated interop
• serialization/deserialization without resorting to {.rename: ....}

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)

Can Stropping be "extended" to allow such styles without adding new syntaxes ?.

i don't think so because it'd create ambiguities + amount of breaking changes it'd introduce:

• proc `foo bar`() (see vmops.nim)
• stropping still uses style insensitivity

hence a special syntax is needed IMO

design goals:

• the new syntax should be exact match, not style insensitive
• it should allow special characters (at least common ones; at least _; maybe : for

type A = `$std::vector`[int]

• whether it should allow spaces is not needed if by not allowing spaces we end up with a nicer syntax

[juancarlospaco]

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

[timotheecour]

I mean double underscore at the start of the identifier name

but if you allow double __foo__ we should also allow _foo and foo_

btw, my proposal for proc !_foo_() has a problem, eg:

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.
It would work by disable style insensitivity if ident starts/ends with _ (ie, require exact match)

[timotheecour]

btw, i was unaware of https://github.com/juancarlospaco/cpython, looks super interesting (but see questions i posted there)

[juancarlospaco]

we should also allow _foo and foo_

Works for me...

and everything would "just work", no breaking change, no ambiguity, since these syntax (start/trail underscore) are currently forbidden.

I like the RFC.