Operator alternatives

[leobalter]

• 50~px: no current syntax for the ~ operator after a number, it's also possible to use it with strings (Why only numeric? Why not extensible string literals? #3): "leo"~utf8. You can even extend the operator to variable names value~px. Only con, if it's a con: single line usage required. No need to extend this proposal to variables for now, but no need to block them either.
• 50@px: same perks of using tilde. AFAICT, decorators won't conflict with this usage if it's in the same line.

[rwaldron]

50~px
"leo"~utf8

Nice.

[littledan]

Those symbols are not initial identifier characters. How do you propose to solve the shadowing issue? What would those desugar to?

[rwaldron]

Those symbols are not initial identifier characters. How do you propose to solve the shadowing issue?

It's clear that you're unwilling to consider any approach that doesn't use the _, so I believe the next step is to write a counter proposal.

[leobalter]

How do you propose to solve the shadowing issue?

I believe the shadowing issue is a subjective problem. I read you want things as px for the extension and at the same time save it for a function/variable px. That's not really solved or fixed by using _ as an operator.

I am opposed to use any valid identifier as an operator for the extension. Add the fact we have proposal conflicts and this extension proposal only creates conflicts using underscore, as already noted in other issues here.

Suggesting let { _px } = CSS; already sounds weird. I'm concerned one needs to publish some api where methods are all named with _:

var Imperial = {
  _f() { ... },
  _in() { ... },
};

let { _f, _in } = Imperial;

let size = 12_in;

I can't find this interesting at all. I'm also not interested to rely on destructuring everywhere:

var Imperial = {
  f() { ... },
  in() { ... },
};

let { f: _f, in: _in } = Imperial;

let size = 12_in;

let { px: _px } = CSS;

...

I already left other advantages of using a non-identifer operator for this, but it sounds the goal here is to trump the NLS stage 3 proposal, where _ doesn't cause any conflicts with names. I found this really unfortunate and weak. I'm not trading that proposal with this.

Shadowing can be easily solved by using small modules, with module names or simply using const (without that syntax error example, please). If you want so much to protect names from shadowing, maybe you should consider registering the extensions. This way you have a better handler to solve shadowing from your own code:

Number.registerExtensions({ px: _px });

I'm still not convinced one might need this so much:

var { px } = CSS;

...

var px = somethingElse;

[littledan]

@rwaldron Trumping another proposal was never a goal. I didn't even realize the overlap when I brought up the idea of following C++'s lead here on using things that started with _. I was just trying to solve the issues the committee brought about this proposal.

It's great if you're going to write another proposal. I don't understand why you are making this "counter-proposal" phrasing--I want to figure out this problem too, and am just bringing up the concerns I've heard raised before.

@leobalter I don't see why this requires destructuring inherently; it could be used through import as well.

About registering a suffix: I'm not sure how to do that without giving JS global mutable state which cannot be hidden using lexical shadowing. My understanding is that @erights would like to avoid this sort of thing.

[rauschma]

I like this idea! Isn’t this the pipeline operator, though? Could the pipeline operator be used here?