"Numeric literal suffixes live in a parallel lexical scope."

[arcanis]

Why is this parallel lexical scope needed? Intuitively I'd expect extended literal suffixes to work similar to template tags, which live in the same global scope as everything else. Is there a practical issue with allowing to use suffixes as soon as they are imported in the module?

[tabatkins]

Common numeric literal suffixes would be short identifiers, which will commonly clash with other variables (especially temp vars). Template functions don't have the same issue; they're usually named more like a normal function.

Using the same lexical scope would also prevent "explaining" the existing numeric suffixes, which definitely are not overridden by an in-scope n variable.

[arcanis]

which definitely are not overridden by an in-scope n variable

Why is that? It's not clear to me why they would behave so differently from template functions. Is the naming being similar to variable the only reason?

If so I'd tend to disagree: regular functions are generally named using a verb, whereas template functions are generally a name - similar to variables. I didn't feel like it caused confusion, though.

[michaelficarra]

@arcanis

Using the same lexical scope would also prevent "explaining" the existing numeric suffixes, which definitely are not overridden by an in-scope n variable.

I think you may have either not read or not appreciated this point.

let n = () => {};
0n;

Today, 0n is already valid syntax using a (built-in) numeric suffix that does not interact in any way with the in-scope binding n. If other numeric suffixes did interact with the in-scope bindings, that would be a weird historical inconsistency that all new users of the language would have to learn.

[arcanis]

Thanks for the example, it's clearer now!

That being said, while I see the concern, it feels somewhat low compared to adding a whole different syntax.

You say it'd be weird to an inexperienced reader authoring a custom unit why n would behave surprisingly, and I agree (I believe only n would be affected, right?). But wouldn't it be more difficult to force everyone who would ever want to simply use custom units (not just author them) to learn a different concept?

Both syntaxes have inconvenience, but it feels to me optimizing for the vastly more common case would yield better results, from a developer experience perspective.