Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder <tj at crowdersoftware.com> wrote:
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
I missed this discussion. What validates the introduction of this
syntax over the equally simple and already possible a = b || 5? Is
the comparison to undefined (and why not ==null as well??) really
worth the introduction (and subsequent loss of future usage) of the
double question mark? Whatever it's usual name is (double wat?).
Would it be possible to use ||| instead? E.g.:
a = b ||| 5;
If the above is "this, absolutely" and such a feature, I favor this as
well because it resembles the a = b || 5 expression better.
(Read that before posting, did not see anything compelling)
If the above is "this, absolutely" and such a feature, I favor this as
Wow, something messed up big time.
"If the above answer is "this, absolute" and such a feature is seriously considered ..."
On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee <ecma at qfox.nl> wrote:
On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder <tj at crowdersoftware.com> wrote:
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
I missed this discussion. What validates the introduction of this syntax over the equally simple and already possible
a = b || 5? Is the comparison toundefined(and why not==nullas well??) really worth the introduction (and subsequent loss of future usage) of the double question mark? Whatever it's usual name is (double wat?).
If b is falsey (0, false, null), it'll use the 5, even though you only intended it to be used when b is undefined.
"undefined" is special-cased here because it's an extremely common value to check against. It's used when an argument isn't supplied, or when you try to pull a non-existent property off of an object.
On Tue, Jun 12, 2012 at 10:56 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
"undefined" is special-cased here because it's an extremely common value to check against. It's used when an argument isn't supplied, or when you try to pull a non-existent property off of an object.
I believe the most common case for an undefined argument is to either provide undefined OR null. I prefer null because it's not a global look up and because it's shorter. So when I have to write a function call with empty parameter I supply null as the argument.
Where I'm going with that is to point out that the specific undefined
(only) case doesn't feel to be a "de facto standard" in the js world
to validate special syntax for it. And even if it did, please let it
take null into account as well. In these cases, who really does x === undefined opposed to just x == null?
On Tue, Jun 12, 2012 at 1:56 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee <ecma at qfox.nl> wrote:
On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder <tj at crowdersoftware.com> wrote:
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
I missed this discussion. What validates the introduction of this syntax over the equally simple and already possible
a = b || 5? Is the comparison toundefined(and why not==nullas well??) really worth the introduction (and subsequent loss of future usage) of the double question mark? Whatever it's usual name is (double wat?).If b is falsey (0, false, null), it'll use the 5, even though you only intended it to be used when b is undefined.
"undefined" is special-cased here because it's an extremely common value to check against. It's used when an argument isn't supplied, or when you try to pull a non-existent property off of an object.
A non-supplied argument is a use-case that is already covered by default parameters.
On the other hand, non-existent properties are a use-case. CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o = a: 1 b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = { a: 1, b: 2 };
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null, like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties use-case should be "undefined"-specific or "null"-specific (or both).
On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On the other hand, non-existent properties are a use-case. CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o = a: 1 b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = { a: 1, b: 2 };
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null, like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties use-case should be "undefined"-specific or "null"-specific (or both).
That's... pretty wrong. In the example above, o.c returns undefined, not null. If CoffeeScript actually compiles to the code you posted, then it only works because they're using != instead of !==, and null and undefined are both falsey. However, it'll break if o.c is defined and is a falsey value like 0 or false.
Try it. Put the following in your nearest console and see what it returns:
({a:1, b:2}).c === undefined
On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On the other hand, non-existent properties are a use-case. CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o = a: 1 b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = { a: 1, b: 2 };
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null, like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties use-case should be "undefined"-specific or "null"-specific (or both).
That's... pretty wrong. In the example above, o.c returns undefined, not null. If CoffeeScript actually compiles to the code you posted, then it only works because they're using != instead of !==, and null and undefined are both falsey. However, it'll break if o.c is defined and is a falsey value like 0 or false.
Try it. Put the following in your nearest console and see what it returns:
({a:1, b:2}).c === undefined
CoffeeScript's property checking returns "undefined" if the property is either undefined or null, and returns the property itself otherwise. If the property is false or 0, it returns the property (either false or 0). I don't understand why you say it breaks if o.c is a falsey value like 0 or false.
The following code:
Boolean.prototype.d = 'Property'
o =
a: 1
b: 2
c: false
alert o.c?.d
will show "Property", as we'd expect.
My point still stands. Being "undefined"-specific is arbitrary. CoffeeScript could have been "undefined"-specific; they were "undefined" + "null"-specific, which I believe makes more sense.
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
My point still stands. Being "undefined"-specific is arbitrary. CoffeeScript could have been "undefined"-specific; they were "undefined" + "null"-specific, which I believe makes more sense.
Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria.
On Tue, Jun 12, 2012 at 10:17 PM, David Herman <dherman at mozilla.com> wrote:
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
My point still stands. Being "undefined"-specific is arbitrary. CoffeeScript could have been "undefined"-specific; they were "undefined" + "null"-specific, which I believe makes more sense.
Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria.
"undefined" and "null" share a lot of behavior that other falsy values don't have. The most critical one is to throw a TypeError on some occasions, including when invoking the abstract ToObject operation. Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance. This lets the user know when a parameter was meant to be set to nothing, and when we should use a default parameter instead. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common. On the other hand, we often want to react in a certain way if the parameter is not set, either because it was not supplied or because it was set to null.
Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Having a way to deal with those return values by providing a default value would be nice.
Thaddee Tyl wrote:
On Tue, Jun 12, 2012 at 10:17 PM, David Herman<dherman at mozilla.com> wrote:
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
My point still stands. Being "undefined"-specific is arbitrary. CoffeeScript could have been "undefined"-specific; they were "undefined" + "null"-specific, which I believe makes more sense. Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria.
"undefined" and "null" share a lot of behavior that other falsy values don't have. The most critical one is to throw a TypeError on some occasions, including when invoking the abstract ToObject operation. Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance.
Yes. I find this pattern a little smelly, though. It is an optimization for V8 - delete foo.x changes foo to plain slow hashtable, but foo.x = null does not.
This lets the user know when a parameter was meant to be set to nothing, and when we should use a default parameter instead. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common.
But here, it is semantic difference - null means "nothing, chosen by will". Undefined means "nothing, as a consequence of not being defined".
On the other hand, we often want to react in a certain way if the parameter is not set, either because it was not supplied or because it was set to null.
I find the "or" here a bit misleading - to react if parameter is not set is to react to undefined.
Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null.
Object.getPrototypeOf(...) return null for a reason. It is not "semantically undefined", it is very well defined, being "the prototype chain stops here, no more parents".
Having a way to deal with those return values by providing a default value would be nice.
As I see it, it is much clearer (in the good code design and style sense) to only react to undefined.
But under "paving the cowpaths" philosophy, I am afraid null+undefined is what will be considered as the implementation.
Herby
P.S.: It also saves more code if ??/?= will react to undefined. Properly testing undefined needs
typeof foo === "undefined"
while properly testing for undefined+null only needs
foo == null
.
P.P.S.: It would be helpful if delete could be made fast in V8 and foo=null discouraged... though I can't imagine how.
On Tue, Jun 12, 2012 at 6:33 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:
On the other hand, non-existent properties are a use-case. CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o = a: 1 b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = { a: 1, b: 2 };
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null, like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties use-case should be "undefined"-specific or "null"-specific (or both).
That's... pretty wrong. In the example above, o.c returns undefined, not null. If CoffeeScript actually compiles to the code you posted, then it only works because they're using != instead of !==, and null and undefined are both falsey. However, it'll break if o.c is defined and is a falsey value like 0 or false.
Try it. Put the following in your nearest console and see what it returns:
({a:1, b:2}).c === undefined
CoffeeScript's property checking returns "undefined" if the property is either undefined or null, and returns the property itself otherwise. If the property is false or 0, it returns the property (either false or 0). I don't understand why you say it breaks if o.c is a falsey value like 0 or false.
The following code:
Boolean.prototype.d = 'Property'
o = a: 1 b: 2 c: false
alert o.c?.d
will show "Property", as we'd expect.
My point still stands. Being "undefined"-specific is arbitrary. CoffeeScript could have been "undefined"-specific; they were "undefined" + "null"-specific, which I believe makes more sense.
Okay, further testing shows that my knowledge was incomplete. Null and undefined compare as double-equal, but neither are double-equal to other falsey values.
However, my argument stands - being undefined-specific is not arbitrary, because that's what is actually returned by such things. Both args without values and properties that don't exist give the value undefined when you try to reference them. Using a double-equal check against null to test for whether something is undefined only works because double-equal is pretty screwed up.
On Jun 12, 2012, at 11:44 PM, Thaddee Tyl wrote:
Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance.
I think this is the key point, but I'm still trying to figure out the implications.
I believe you're right, and I think it calls into question the "undefined means no-value, null means no-object" mantra. In practice, I think it's really "undefined means uninitialized, null means no-value."
Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common.
This confuses me. If default parameters don't treat null as requiring a default, won't that work against this pattern?
Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Having a way to deal with those return values by providing a default value would be nice.
That's a pretty strong argument IMO.
Dave, still mulling
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null and undefined compare as double-equal, but neither are double-equal to other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users immediately tested o.p != null to existing-check. There was even some confusion where missing array elements in primordial JS evaluated to null not undefined. Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not arbitrary, because that's what is actually returned by such things. Both args without values and properties that don't exist give the value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist, though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather than using delete doesn't argue for defaulting based on LHS value in {null, undefined}.
Using a double-equal check against null to test for whether something is undefined only works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or biology. Not just Homer Simpson "Life is just a bunch of things that happen" randomness, mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null and undefined are confusingly similar, in part due to being ==. This is true, but I still do not see actual use-cases where null is passed into code that uses || to select a default value. Would love to see such real-world code.
My two sense. In my experience (large applications, rather than tight libraries), distinguishing between null and undefined is the exception, not the rule. When it is distinguished, as often as not the author would be more correct in either including null or making an property existence check (foo in bar) rather than an explicit check for undefined.
In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null = my error and I should use the API more correctly.
On Jun 14, 2012, at 11:27, "John Lenz" <concavelenz at gmail.com<mailto:concavelenz at gmail.com>> wrote:
My two sense. In my experience (large applications, rather than tight libraries), distinguishing between null and undefined is the exception, not the rule. When it is distinguished, as often as not the author would be more correct in either including null or making an property existence check (foo in bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich <brendan at mozilla.org<mailto:brendan at mozilla.org>> wrote:
Tab Atkins Jr. wrote: Okay, further testing shows that my knowledge was incomplete. Null and undefined compare as double-equal, but neither are double-equal to other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users immediately tested o.p != null to existing-check. There was even some confusion where missing array elements in primordial JS evaluated to null not undefined. Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not arbitrary, because that's what is actually returned by such things. Both args without values and properties that don't exist give the value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist, though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather than using delete doesn't argue for defaulting based on LHS value in {null, undefined}.
Using a double-equal check against null to test for whether something is undefined only works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or biology. Not just Homer Simpson "Life is just a bunch of things that happen" randomness, mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null and undefined are confusingly similar, in part due to being ==. This is true, but I still do not see actual use-cases where null is passed into code that uses || to select a default value. Would love to see such real-world code.
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola < domenic at domenicdenicola.com> wrote:
In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist.
null is intentional, its presence is explicit -- doesn't this imply that something does exist? (...and its value is null)
On Jun 14, 2012, at 14:03, "Rick Waldron" <waldron.rick at gmail.com<mailto:waldron.rick at gmail.com>> wrote:
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola <domenic at domenicdenicola.com<mailto:domenic at domenicdenicola.com>> wrote:
In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist.
null is intentional, its presence is explicit -- doesn't this imply that something does exist? (...and its value is null)
Rick
Right, I wasn't exactly clear—I meant more the case of e.g. "nothing exists in the database, so I gave you back a null" or even "there wasn't any error, so I called you back with a null as the first param."
I think the original thrust of this thread may have got lost a bit in the (useful) discussion of null and undefined, so coming back to the original point:
On 12 June 2012 16:29, T.J. Crowder <tj at crowdersoftware.com> wrote:
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
Would it be possible to use ||| instead? E.g.:
a = b ||| 5;
I ask because I was planning (prior to knowing about this strawman!) to suggest that, along with a different form of ?? (or ???) which introduces a new ternary operator:
a = b ?? 5 : 6;
...which would be a shorthand form of
a = b !== undefined ? 5 : 6;
Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't need it), Brendan's ("too thin")[1], and Herby's ("wouldn't hurt")[2].
(Speaking syntactically, I think we all agreed in the other thread that ||| [above] won't work for the infix, because the assignment form just becomes too confusing, as Wes pointed out.[3])
[1] esdiscuss/2012-June/023468 [2] esdiscuss/2012-June/023510 [3] esdiscuss/2012-June/023386
-- T.J.
On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowder <tj at crowdersoftware.com> wrote:
Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't need it), Brendan's ("too thin")[1], and Herby's ("wouldn't hurt")[2].
Since you are asking for opinions.
I don't want it. It doesn't carry its own weight.
Erik Arvidsson wrote:
On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowder<tj at crowdersoftware.com> wrote:
Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't need it), Brendan's ("too thin")[1], and Herby's ("wouldn't hurt")[2].
Since you are asking for opinions.
I don't want it. It doesn't carry its own weight.
If everyone's opinion carries weight, then we are tied :-P. Kidding.
But aside from opinions and their weight, we have a problem if "wouldn't hurt" is the answer for syntax proposals. New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise.
So the summary (sorry if it didn't do Herby's position justice; I'm using it as a whipping boy here) of "wouldn't hurt" is simply not an argument for new operators to shorten hard cases.
On 15 June 2012 22:22, Brendan Eich <brendan at mozilla.org> wrote:
If everyone's opinion carries weight, then we are tied :-P. Kidding.
But aside from opinions and their weight, we have a problem if "wouldn't hurt" is the answer for syntax proposals.
Who said it was?
New syntax does hurt. It hurts by requiring a transpiler or full compiler
to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise.
I'm sorry: "botched"?! What exactly is "botched" about this? In fact, I don't think I was pushing any particular syntax. I think I was clear about asking whether people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question?
-- T.J.
T.J. Crowder wrote:
On 15 June 2012 22:22, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if "wouldn't hurt" is the answer for syntax proposals.Who said it was?
You summarized Herby to that effect:
"Herby's ("wouldn't hurt")[2].
...
[2] esdiscuss/2012-June/023510 "
New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise.I'm sorry: "botched"?! What exactly is "botched" about this?
You are misreading my generic words. I'm not talking about a proposal of yours, or of mine.
In fact, I don't think I was pushing any particular syntax. I think I was clear about asking whether people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question?
I was describing the hazards of adding syntax that "wouldn't hurt". Syntax should be added only when it clearly helps:
- It brings new semantics not expressible in the language (let, const, modules, generators).
- It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded.
Brendan Eich wrote:
- It brings new semantics not expressible in the language (let, const, modules, generators).
- It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded.
Classes (maximally minimal, mainly for extends and super) is a prime example of the second bullet, IMHO.
Apologies if my reply seemed targeted at you, or Herby for that matter. I was soap-boxing against the "wouldn't hurt" summary-argument.
On 16 June 2012 01:44, Brendan Eich <brendan at mozilla.com> wrote:
T.J. Crowder wrote:
On 15 June 2012 22:22, Brendan Eich <brendan at mozilla.org <mailto:
brendan at mozilla.org>> wrote:
If everyone's opinion carries weight, then we are tied :-P. Kidding.
But aside from opinions and their weight, we have a problem if "wouldn't hurt" is the answer for syntax proposals.
Who said it was?
You summarized Herby to that effect:
Ah, sorry -- apparently copy-and-paste doesn't stick in the memory, I didn't recall that phrasing.
-- T.J.
Brendan Eich wrote:
In fact, I don't think I was pushing any particular syntax. I think I was clear about asking whether people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question?
I was describing the hazards of adding syntax that "wouldn't hurt". Syntax should be added only when it clearly helps:
- It brings new semantics not expressible in the language (let, const, modules, generators).
- It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded.
I'm from different school of thinking which is probably very incovenient in spec-thinking. But I feel strongly that there should be one more category:
- It is an affordance with very little or no new semantic for an uncommon pattern which by its formalizing and makes "godel-accessible" (in the sense "comprehensible by one's mind") space covered by the language much greater. (I'm talking about mixins / traits, mustache+richer data semantics, ... Things that can be done, but the price is hard, so they are not used. But that goes directly against "paving the cowpath" and "no novelties". Basically what I am advocating here probably are novelties. :-/ )
Herby Vojčík wrote:
Brendan Eich wrote:
In fact, I don't think I was pushing any particular syntax. I think I was clear about asking whether people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question?
I was describing the hazards of adding syntax that "wouldn't hurt". Syntax should be added only when it clearly helps:
- It brings new semantics not expressible in the language (let, const, modules, generators).
- It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded.
I'm from different school of thinking which is probably very incovenient in spec-thinking. But I feel strongly that there should be one more category:
- It is an affordance with very little or no new semantic for an uncommon pattern which by its formalizing and makes "godel-accessible"
s/and//
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
Would it be possible to use ||| instead? E.g.:
a = b ||| 5;
I ask because I was planning (prior to knowing about this strawman!) to suggest that, along with a different form of ?? (or ???) which introduces a new ternary operator:
a = b ?? 5 : 6;
...which would be a shorthand form of
a = b !== undefined ? 5 : 6;
[1] strawman:default_operator
-- T.J.