Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

>From a technical point of view, using ![ instead of ?.[ may work only if you 
>forbid a line terminator before the !

I tried this on [TS 
Playground](http://www.typescriptlang.org/play/#src=var%20a%20%3D%20%7B%7D%3B%0D%0A%0D%0Aa!%5B3%5D%3B%0D%0Aa%0D%0A!%5B3%5D%3B)
 and it interestingly changes behavior when there is a line break before `!`.

```js
var a = {};

a![3]; // works as a[3]
a
![3]; // preserves original behavior
```

>but many languages (e.g. Swift, Kotlin, and I think TypeScript 2.0) use it in 
>the inverse direction: non-null assertion for nullable types.

Right. :/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

>Why is this needed? Why are people trying to get the property of an object 
>which is null?

I will appreciate null propagation when a function receives an “option bag”

```js
function someFunction(options) {
  if(options?.foo) {
doSomething();
  };
}

someFunction();
someFunction({ foo: true });
```

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

It may be a good idea to create a pull request for it if it isn't listed
yet (search "null propagation JavaScript"). I know there's a proposal
written out (I've seen it), I just don't recall the exact URL offhand nor
if there's a champion or not, but I thought it did. It could be one of
those looking for a new champion (that's why the bind operator proposal has
also stagnated).

On Thu, Oct 13, 2016, 11:14 Kagami Rosylight  wrote:

>
>
> >IIRC the proposed syntax for computed properties was x?.[y],
>
>
>
> Yes you’re right, sorry :/
>
>
>
> IMO it still seems the syntax problem is the main reason why this proposal
> has stalled. If not, what is the problem here? I’m curious why this
> proposal is not even listed in stage 0 proposal list.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

>IIRC the proposed syntax for computed properties was x?.[y],

Yes you’re right, sorry :/

IMO it still seems the syntax problem is the main reason why this proposal has 
stalled. If not, what is the problem here? I’m curious why this proposal is not 
even listed in stage 0 proposal list.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

IIRC the proposed syntax for computed properties was `x?.[y]`, to avoid the
ambiguity.

On Thu, Oct 13, 2016, 10:24 Kagami Rosylight  wrote:

>
>
> >The token ?. works fine
>
>
>
> I think more than half of this thread is about syntactic ambiguity,
> regardless of whether the ambiguity is real or not. For example, from [an
> earlier post of this thread](
> https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44
> ):
>
>
>
> >But what should be done with cases like obj?[1]?[2]:[3].
>
>
>
> A formatter may help this and make it `obj?[1] ? [2] : [3]` or `obj ?
> [1]?[2] : [3]` depending on operator precedence, but shouldn’t it be more
> clear? `obj![1]?[2]:[3]` will not be confused with ternary operator.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

>The token ?. works fine

I think more than half of this thread is about syntactic ambiguity, regardless 
of whether the ambiguity is real or not. For example, from [an earlier post of 
this 
thread](https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44):

>But what should be done with cases like obj?[1]?[2]:[3].

A formatter may help this and make it `obj?[1] ? [2] : [3]` or `obj ? [1]?[2] : 
[3]` depending on operator precedence, but shouldn’t it be more clear? 
`obj![1]?[2]:[3]` will not be confused with ternary operator.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

TypeScript can change if it has to, and it's done so before (ES modules are
a good example of this). They try their best to be a strict superset of
ECMAScript, and this even goes as far as making type errors early warnings,
not early errors, by default (the latter would technically be a violation
of section 16, paragraph 3).

On Thu, Oct 13, 2016, 08:37 Kagami Rosylight  wrote:

>
>
> Or `!.`, which unfortunately is now being used by TypeScript?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

Or `!.`, which unfortunately is now being used by TypeScript?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kagami Rosylight]

Is the only problem here is the parser problem with `obj.prop?.2:.1`? Then how 
about `??. ` instead of `?.`? 

>Once upon a time, there was a fascinating proposal on this subject:

Why are you posting twice? :/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[John Lenz]

It is a parser problem:

obj.prop?.2:.1

You need arbitrary look ahead to disambiguate ?. from ?: solve the problem.

On Tue, May 10, 2016 at 10:32 AM,  wrote:

> Why isn't it possible to use the obj.property?.sub syntax in combination
> with lookahead as suggested by Brendan Eich 4 years ago?
>
> http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[mads . k]

Why isn't it possible to use the obj.property?.sub syntax in combination
with lookahead as suggested by Brendan Eich 4 years ago? 

http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator

  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Laurentiu Macovei]

This would be amazing operator!!

var error = a.b.c.d; //this would fail with error if a, b or c are null or
undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above
mess with no errors

However I propose a more clear one - as not to confuse ? from the a ? b : c
statements with a?.b statements:

var x = a..b..c..d; //this would be ideal to understand that you assume
that if any of a, b, c is null or undefined the result will be null or
undefined.

Two dots, means if its null or undefined stop processing further and assume
the result of expression is null or undefined. (as d would be null or
undefined).

Two dots make it more clear, more visible and more space-wise so you
understand what's going on.

What do you think folks?



Best Regards,
Laurenţiu Macovei
DotNetWise
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Maël Nison]

As a side note, this feature has recently been added to Ruby (issue
). They use the
"foo.?bar" syntax instead of "foo?.bar" because of a grammar conflict (ruby
identifiers may end with an interrogation mark).

Is there something wrong with the "foo?.bar" syntax? It seems to be
supported about anywhere (where this feature is implemented, at least), so
anything else might be a bit confusing for most users.

The following language implement this feature and syntax: C#, Groovy,
Swift, Ruby (with a twist)

Le jeu. 29 oct. 2015 à 19:53, Laurentiu Macovei 
a écrit :

> Yes! I have updated my answer using markdown and also posted on the
> original issue of TypeScript.
> https://github.com/Microsoft/TypeScript/issues/16
> Is there a better place to propose it for `ES6`/`ES7` ?
>
> This would be amazing operator!! Especially for `ES6`/`ES7`/`TypeScript`
>
> ```js
> var error = a.b.c.d; //this would fail with error if a, b or c are null or
> undefined.
> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
> handle this
> var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d'];
> //the current messy way to handle this
> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
> mess with no errors
> var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling
> the above mess with no errors
> ```
> However I propose a more clear one - as not to confuse ? from the a ? b :
> c statements with a?.b statements:
>
> ```js
> var doubleDots = a..b..c..d; //this would be ideal to understand that you
> assume that if any of a, b, c is null or undefined the result will be null
> or undefined.
> var doubleDotsWithBrackets = a..['b']..['c']..['d'];
> ```
>
> For the bracket notation, I recommend two dots instead of a single one as
> it's consistent with the others when non brackets are used. Hence only the
> property name is static or dynamic via brackets.
>
> Two dots, means if its null or undefined stop processing further and
> assume the result of expression is null or undefined. (as d would be null
> or undefined).
>
> Two dots make it more clear, more visible and more space-wise so you
> understand what's going on.
>
> This is not messing with numbers too - as is not the same case e.g.
>
> ```js
> 1..toString(); // works returning '1'
> var x = {};
> x.1 = {y: 'test' }; //fails currently
> x[1] = {y: 'test' }; //works currently
> var current = x[1].y; //works
> var missing= x[2].y; //throws exception
> var assume= x && x[2] && x[2].y; // works but very messy
> ```
>
> About numbers two options: Your call which one can be adopted, but I
> recommend first one for compatibility with existing rules!
> 1. Should fail as it does now (`x.1.y` == `runtime error`)
> ```js
> var err = x..1..y; // should fail as well, since 1 is not a good property
> name, nor a number to call a method, since it's after x object.
> ```
> 2. Should work since it understands that is not a number calling a
> property from `Number.prototype`
> ```js
> var err = x..1..y; // should work as well, resulting 'test' in this case
> var err = x..2..y; // should work as well, resulting undefined in this case
> ```
>
>
> With dynamic names:
> ```js
> var correct1 = x..[1]..y; //would work returning 'test'
> var correct2 = x..[2]..y; //would work returning undefined;
> ```
>
> What do you think folks?
>
>
> Best Regards,
> Laurenţiu Macovei
>
> On Thu, Oct 29, 2015 at 7:29 PM, Sander Deryckere 
> wrote:
>
>>
>>
>> 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei :
>>
>>> This would be amazing operator!!
>>>
>>> var error = a.b.c.d; //this would fail with error if a, b or c are null
>>> or undefined.
>>> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
>>> handle this
>>> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
>>> mess with no errors
>>>
>>> However I propose a more clear one - as not to confuse ? from the a ? b
>>> : c statements with a?.b statements:
>>>
>>> var x = a..b..c..d; //this would be ideal to understand that you assume
>>> that if any of a, b, c is null or undefined the result will be null or
>>> undefined.
>>>
>>> Two dots, means if its null or undefined stop processing further and
>>> assume the result of expression is null or undefined. (as d would be null
>>> or undefined).
>>>
>>> Two dots make it more clear, more visible and more space-wise so you
>>> understand what's going on.
>>>
>>> What do you think folks?
>>>
>>>
>> Do you also have a proposal on how to handle a["b"]["c"]["d"], so with
>> possibly variable keys.
>>
>> In any case, I think that the existential operator (whatever the exact
>> sign used is) will be better then the current way of chaining &&.
>>
>> Regards,
>> Sander
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> 

Re: Re: Existential Operator / Null Propagation Operator

[Angel Java Lopez]

Proposal for variable keys:

a.["b"].["c"].["d"]


On Thu, Oct 29, 2015 at 3:32 PM, Eli Perelman  wrote:

> 2 dots may be problematic when parsing numbers (yeah, I know it's probably
> not common, but it's still valid):
>
> 3..toString()
>
> Eli Perelman
>
> On Thu, Oct 29, 2015 at 1:29 PM, Sander Deryckere 
> wrote:
>
>>
>>
>> 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei :
>>
>>> This would be amazing operator!!
>>>
>>> var error = a.b.c.d; //this would fail with error if a, b or c are null
>>> or undefined.
>>> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
>>> handle this
>>> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
>>> mess with no errors
>>>
>>> However I propose a more clear one - as not to confuse ? from the a ? b
>>> : c statements with a?.b statements:
>>>
>>> var x = a..b..c..d; //this would be ideal to understand that you assume
>>> that if any of a, b, c is null or undefined the result will be null or
>>> undefined.
>>>
>>> Two dots, means if its null or undefined stop processing further and
>>> assume the result of expression is null or undefined. (as d would be null
>>> or undefined).
>>>
>>> Two dots make it more clear, more visible and more space-wise so you
>>> understand what's going on.
>>>
>>> What do you think folks?
>>>
>>>
>> Do you also have a proposal on how to handle a["b"]["c"]["d"], so with
>> possibly variable keys.
>>
>> In any case, I think that the existential operator (whatever the exact
>> sign used is) will be better then the current way of chaining &&.
>>
>> Regards,
>> Sander
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Laurentiu Macovei]

 `foo?.bar` and `foo?['bar']` syntax would work too.

However the using both current `?` `:` operator and `?.` might be very
confusing on the same line.

e.g. using `?.` and `?['prop']`
```js
var a = { x: { y: 1 } };
var b = condition ? a?.x.?y : a?.y?.z;
var c = condition ? a?['x']?['y'] : a?['y']?['z'];
```
as opposed to double dots `..` and `..['prop']`
```js
var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];
```

# Which one does look more clear to you?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Sander Deryckere]

2015-10-29 19:22 GMT+01:00 Laurentiu Macovei :

> This would be amazing operator!!
>
> var error = a.b.c.d; //this would fail with error if a, b or c are null or
> undefined.
> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
> handle this
> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
> mess with no errors
>
> However I propose a more clear one - as not to confuse ? from the a ? b :
> c statements with a?.b statements:
>
> var x = a..b..c..d; //this would be ideal to understand that you assume
> that if any of a, b, c is null or undefined the result will be null or
> undefined.
>
> Two dots, means if its null or undefined stop processing further and
> assume the result of expression is null or undefined. (as d would be null
> or undefined).
>
> Two dots make it more clear, more visible and more space-wise so you
> understand what's going on.
>
> What do you think folks?
>
>
Do you also have a proposal on how to handle a["b"]["c"]["d"], so with
possibly variable keys.

In any case, I think that the existential operator (whatever the exact sign
used is) will be better then the current way of chaining &&.

Regards,
Sander
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Eli Perelman]

2 dots may be problematic when parsing numbers (yeah, I know it's probably
not common, but it's still valid):

3..toString()

Eli Perelman

On Thu, Oct 29, 2015 at 1:29 PM, Sander Deryckere 
wrote:

>
>
> 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei :
>
>> This would be amazing operator!!
>>
>> var error = a.b.c.d; //this would fail with error if a, b or c are null
>> or undefined.
>> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
>> handle this
>> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
>> mess with no errors
>>
>> However I propose a more clear one - as not to confuse ? from the a ? b :
>> c statements with a?.b statements:
>>
>> var x = a..b..c..d; //this would be ideal to understand that you assume
>> that if any of a, b, c is null or undefined the result will be null or
>> undefined.
>>
>> Two dots, means if its null or undefined stop processing further and
>> assume the result of expression is null or undefined. (as d would be null
>> or undefined).
>>
>> Two dots make it more clear, more visible and more space-wise so you
>> understand what's going on.
>>
>> What do you think folks?
>>
>>
> Do you also have a proposal on how to handle a["b"]["c"]["d"], so with
> possibly variable keys.
>
> In any case, I think that the existential operator (whatever the exact
> sign used is) will be better then the current way of chaining &&.
>
> Regards,
> Sander
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Laurentiu Macovei]

Yes! I have updated my answer using markdown and also posted on the
original issue of TypeScript.
https://github.com/Microsoft/TypeScript/issues/16
Is there a better place to propose it for `ES6`/`ES7` ?

This would be amazing operator!! Especially for `ES6`/`ES7`/`TypeScript`

```js
var error = a.b.c.d; //this would fail with error if a, b or c are null or
undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
handle this
var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d']; //the
current messy way to handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above
mess with no errors
var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling
the above mess with no errors
```
However I propose a more clear one - as not to confuse ? from the a ? b : c
statements with a?.b statements:

```js
var doubleDots = a..b..c..d; //this would be ideal to understand that you
assume that if any of a, b, c is null or undefined the result will be null
or undefined.
var doubleDotsWithBrackets = a..['b']..['c']..['d'];
```

For the bracket notation, I recommend two dots instead of a single one as
it's consistent with the others when non brackets are used. Hence only the
property name is static or dynamic via brackets.

Two dots, means if its null or undefined stop processing further and assume
the result of expression is null or undefined. (as d would be null or
undefined).

Two dots make it more clear, more visible and more space-wise so you
understand what's going on.

This is not messing with numbers too - as is not the same case e.g.

```js
1..toString(); // works returning '1'
var x = {};
x.1 = {y: 'test' }; //fails currently
x[1] = {y: 'test' }; //works currently
var current = x[1].y; //works
var missing= x[2].y; //throws exception
var assume= x && x[2] && x[2].y; // works but very messy
```

About numbers two options: Your call which one can be adopted, but I
recommend first one for compatibility with existing rules!
1. Should fail as it does now (`x.1.y` == `runtime error`)
```js
var err = x..1..y; // should fail as well, since 1 is not a good property
name, nor a number to call a method, since it's after x object.
```
2. Should work since it understands that is not a number calling a property
from `Number.prototype`
```js
var err = x..1..y; // should work as well, resulting 'test' in this case
var err = x..2..y; // should work as well, resulting undefined in this case
```


With dynamic names:
```js
var correct1 = x..[1]..y; //would work returning 'test'
var correct2 = x..[2]..y; //would work returning undefined;
```

What do you think folks?


Best Regards,
Laurenţiu Macovei

On Thu, Oct 29, 2015 at 7:29 PM, Sander Deryckere 
wrote:

>
>
> 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei :
>
>> This would be amazing operator!!
>>
>> var error = a.b.c.d; //this would fail with error if a, b or c are null
>> or undefined.
>> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
>> handle this
>> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
>> mess with no errors
>>
>> However I propose a more clear one - as not to confuse ? from the a ? b :
>> c statements with a?.b statements:
>>
>> var x = a..b..c..d; //this would be ideal to understand that you assume
>> that if any of a, b, c is null or undefined the result will be null or
>> undefined.
>>
>> Two dots, means if its null or undefined stop processing further and
>> assume the result of expression is null or undefined. (as d would be null
>> or undefined).
>>
>> Two dots make it more clear, more visible and more space-wise so you
>> understand what's going on.
>>
>> What do you think folks?
>>
>>
> Do you also have a proposal on how to handle a["b"]["c"]["d"], so with
> possibly variable keys.
>
> In any case, I think that the existential operator (whatever the exact
> sign used is) will be better then the current way of chaining &&.
>
> Regards,
> Sander
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

[Laurentiu Macovei]

Ron,

Javascript only works by `assumptions`, that the developer made at the time
the code was written than at runtime they will be the same (and not
changing by newly ESX).

So, it does NOT make sense to change the code that currently works
(expecting to throw error) so that would silently return `null` or
`undefined`
The behavior of the code would change and perhaps over 90% of the existing
libraries would not work anymore.

By wrapping code in `try` / `catch` is actually even worse - as adds way
extra code and extra penalty in performance.
Exceptions should not be used for anything but exception-edge cases.

So I presume the answer to your proposals is no and no.

And btw, the `?.` is already available in languages like [`Groovy`](
http://therealdanvega.com/blog/2013/08/20/groovys-null-safe-operator),
[`Swift`](
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html)
and proposed for [`c# 6.0`](
https://github.com/dotnet/roslyn/issues/5032#issuecomment-152303841). Even
[`Ruby`](https://bugs.ruby-lang.org/issues/11537#note-34) has a proposal
for the opposite one `.?` doing the same thing.

However as I have clarified above `var result = condition ? a?.b?.c?.d :
a?.x?.c?.d;` is way unclear / worse, in my opinion, than `var result =
condition ? a..b..c..d : a..x..c..d;`


Best Regards,
Laurenţiu Macovei
DotNetWise

On Thu, Oct 29, 2015 at 8:30 PM, Ron Waldon  wrote:

> Has anyone considering just making dot-property access return intermediate
> undefined or null values by default?
>
> Not having to introduce new syntax would be a bonus. I'm trying to think
> of existing code that this would break and can't think of any good examples.
>
> The only compatibility issue I have thought of so far is code that relies
> on an Error being thrown but also does not check the value:
>
> ```js
> let value;
> try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
> // use value without even a basic truthy test
> ```
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

[Isiah Meadows]

I strongly oppose. I already write a ton of code that relies on that
throwing, using that for testing purposes. I'd rather something throw
violently than to silently fail in an unexpected, potentially seemingly
unrelated place. Not even pure functional programming can act as a safety
net for implicit undefined/null access.

On Thu, Oct 29, 2015, 15:30 Ron Waldon <jokeyrh...@gmail.com> wrote:

> Has anyone considering just making dot-property access return intermediate
> undefined or null values by default?
>
> Not having to introduce new syntax would be a bonus. I'm trying to think
> of existing code that this would break and can't think of any good examples.
>
> The only compatibility issue I have thought of so far is code that relies
> on an Error being thrown but also does not check the value:
>
> ```js
> let value;
> try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
> // use value without even a basic truthy test
> ```
>
> On Fri, 30 Oct 2015, 06:07  <es-discuss-requ...@mozilla.org> wrote:
>
>
> -- Forwarded message --
> From: Laurentiu Macovei <laurentiu.maco...@gmail.com>
> To: Sander Deryckere <sander...@gmail.com>
> Cc: "es-discuss@ <es-discuss@mozilla.org>mozilla.org
> <es-discuss@mozilla.org> list" <es-discuss@mozilla.org>
> Date: Thu, 29 Oct 2015 19:52:37 +0100
> Subject: Re: Re: Existential Operator / Null Propagation Operator
>
> Yes! I have updated my answer using markdown and also posted on the
> original issue of TypeScript. https
> <https://github.com/Microsoft/TypeScript/issues/16>://
> <https://github.com/Microsoft/TypeScript/issues/16>github.com
> <https://github.com/Microsoft/TypeScript/issues/16>/Microsoft/
> <https://github.com/Microsoft/TypeScript/issues/16>TypeScript
> <https://github.com/Microsoft/TypeScript/issues/16>/issues/16
> <https://github.com/Microsoft/TypeScript/issues/16>
>
> Is there a better place to propose it for `ES6`/`ES7` ?
>
> This would be amazing operator!! Especially for `ES6`/`ES7`/`TypeScript`
>
> ```js
>
> var error = a.b.c.d; //this would fail with error if a, b or c are null or
> undefined.
>
> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
> handle this
>
> var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d'];
> //the current messy way to handle this
>
> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
> mess with no errors
>
> var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling
> the above mess with no errors
>
> ```
>
> However I propose a more clear one - as not to confuse ? from the a ? b :
> c statements with a?.b statements:
>
> ```js
>
> var doubleDots = a..b..c..d; //this would be ideal to understand that you
> assume that if any of a, b, c is null or undefined the result will be null
> or undefined.
>
> var doubleDotsWithBrackets = a..['b']..['c']..['d'];
>
> ```
>
> For the bracket notation, I recommend two dots instead of a single one as
> it's consistent with the others when non brackets are used. Hence only the
> property name is static or dynamic via brackets.
>
> Two dots, means if its null or undefined stop processing further and
> assume the result of expression is null or undefined. (as d would be null
> or undefined).
>
> Two dots make it more clear, more visible and more space-wise so you
> understand what's going on.
>
> This is not messing with numbers too - as is not the same case e.g.
>
> ```js
>
> 1..toString(); // works returning '1'
>
> var x = {};
>
> x.1 = {y: 'test' }; //fails currently
>
> x[1] = {y: 'test' }; //works currently
>
> var current = x[1].y; //works
>
> var missing= x[2].y; //throws exception
>
> var assume= x && x[2] && x[2].y; // works but very messy
>
> ```
>
> About numbers two options: Your call which one can be adopted, but I
> recommend first one for compatibility with existing rules!
>
> 1. Should fail as it does now (`x.1.y` == `runtime error`)
>
> ```js
>
> var err = x..1..y; // should fail as well, since 1 is not a good property
> name, nor a number to call a method, since it's after x object.
>
> ```
>
> 2. Should work since it understands that is not a number calling a
> property from `Number.prototype`
>
> ```js
>
> var err = x..1..y; // should work as well, resulting 'test' in this case
>
> var err = x..2..y; // should work as well, resulting undefined in this case
>
> ```
>
> With dynamic names:
>
> ```js
>
> var correct1 = x..[1]..y; //would work returning 'test'
>
> var correct2 = x..[2]..y; //would work returning undefined;
>
> ```
>
> What do you think folks?
>
> Best Regards,
>
> Laurenţiu Macovei
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Andreas Rossberg]

On 19 August 2015 at 16:21, Tingan Ho tinga...@gmail.com wrote:

 Strange why do they need an operator for that? Probably to make it less
 error prone with access nil errors. But that could be fixed with static
 code analysis.


OT but: The whole point of optional values (as opposed to
null/nil/undefined inhabiting everything) is to make the boundaries of
optionality explicit, thereby avoiding Hoare's billion dollar mistake.

That said, convenient operators like ! already destroy half the benefit.
Plenty of experience from other languages like ML or Haskell shows that
they are almost always used incorrectly (read: over-optimistically). If a
language has to have such an operator, it should at least be very explicit
and as inconvenient as bearable.

/Andreas


On Wed, Aug 19, 2015 at 10:09 PM, Kevin Smith zenpars...@gmail.com wrote:


 In TypeScript `?` means optional. But throw if the value is nil is the
 same same as non-nullable?


 In Swift, the postfix ! operator unwraps an optional value, throwing if
 nil.

 See
 https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html




 --
 Sincerely,

 Tingan Ho
 @tingan87 https://twitter.com/tingan87

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 What about `a!?.b` since semantically the symbol `!` has a meaning of
 non-nullable in JSDoc[1].


! in this context typically means non-optional, or throw if the value is
nill.  See Swift for example.

Or just `a!.b`?


Same thing.

Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Kevin Smith]

 In TypeScript `?` means optional. But throw if the value is nil is the
 same same as non-nullable?


In Swift, the postfix ! operator unwraps an optional value, throwing if
nil.

See
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Tingan Ho]

In TypeScript `?` means optional. But throw if the value is nil is the same
same as non-nullable?

On Wed, Aug 19, 2015 at 9:24 PM, Kevin Smith zenpars...@gmail.com wrote:

 What about `a!?.b` since semantically the symbol `!` has a meaning of
 non-nullable in JSDoc[1].


 ! in this context typically means non-optional, or throw if the value
 is nill.  See Swift for example.

 Or just `a!.b`?


 Same thing.

 Kevin




-- 
Sincerely,

Tingan Ho
@tingan87 https://twitter.com/tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Tingan Ho]

Strange why do they need an operator for that? Probably to make it less
error prone with access nil errors. But that could be fixed with static
code analysis.

On Wed, Aug 19, 2015 at 10:09 PM, Kevin Smith zenpars...@gmail.com wrote:


 In TypeScript `?` means optional. But throw if the value is nil is the
 same same as non-nullable?


 In Swift, the postfix ! operator unwraps an optional value, throwing if
 nil.

 See
 https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html




-- 
Sincerely,

Tingan Ho
@tingan87 https://twitter.com/tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Tingan Ho]

One thing to keep in mind is that with prefix operator `?a.b` will also let
people move back and forth with their caret. Since most people type the
identifier first and then the operator. So they type `a` first and the move
the caret in front of `a` and type `?` and then move the caret back to the
last position and then type `.b`. This has been a big problem in typing
type assertions in TS which had a prefix operator. They later introduced
the `as` operator which is a postfix operator.

What about `a!?.b` since semantically the symbol `!` has a meaning of
non-nullable in JSDoc[1]. So the semantics of  `a!?.` is `is it not null
then the accessor ...`.

Or just `a!.b`?

[1]: Non-nullable type — http://usejsdoc.org/tags-type.html

-- 
Sincerely,

Tingan Ho
@tingan87 https://twitter.com/tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

-1 for the `!` idea. It feels redundant to me, since if you try calling an
undefined value, it'll throw errors at you. It doesn't seem to insure
anything extra beyond current behavior.

On Wed, Aug 19, 2015, 02:27 Tingan Ho tinga...@gmail.com wrote:

 One thing to keep in mind is that with prefix operator `?a.b` will also
 let people move back and forth with their caret. Since most people type the
 identifier first and then the operator. So they type `a` first and the move
 the caret in front of `a` and type `?` and then move the caret back to the
 last position and then type `.b`. This has been a big problem in typing
 type assertions in TS which had a prefix operator. They later introduced
 the `as` operator which is a postfix operator.

 What about `a!?.b` since semantically the symbol `!` has a meaning of
 non-nullable in JSDoc[1]. So the semantics of  `a!?.` is `is it not null
 then the accessor ...`.

 Or just `a!.b`?

 [1]: Non-nullable type — http://usejsdoc.org/tags-type.html

 --
 Sincerely,

 Tingan Ho
 @tingan87 https://twitter.com/tingan87
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Tingan Ho]

I don't see the redundancy? In my proposal the original proposed symbol `?`
is switched with `!`. So it shouldn't throw any error?

On Wed, Aug 19, 2015 at 4:42 PM, Isiah Meadows isiahmead...@gmail.com
wrote:

 -1 for the `!` idea. It feels redundant to me, since if you try calling an
 undefined value, it'll throw errors at you. It doesn't seem to insure
 anything extra beyond current behavior.

 On Wed, Aug 19, 2015, 02:27 Tingan Ho tinga...@gmail.com wrote:

 One thing to keep in mind is that with prefix operator `?a.b` will also
 let people move back and forth with their caret. Since most people type the
 identifier first and then the operator. So they type `a` first and the move
 the caret in front of `a` and type `?` and then move the caret back to the
 last position and then type `.b`. This has been a big problem in typing
 type assertions in TS which had a prefix operator. They later introduced
 the `as` operator which is a postfix operator.

 What about `a!?.b` since semantically the symbol `!` has a meaning of
 non-nullable in JSDoc[1]. So the semantics of  `a!?.` is `is it not null
 then the accessor ...`.

 Or just `a!.b`?

 [1]: Non-nullable type — http://usejsdoc.org/tags-type.html

 --
 Sincerely,

 Tingan Ho
 @tingan87 https://twitter.com/tingan87
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Sincerely,

Tingan Ho
@tingan87 https://twitter.com/tingan87
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Caitlin Potter]

 On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich brendan at mozilla.org 
 https://mail.mozilla.org/listinfo/es-discuss wrote:

* Did you keep backward compatibility? `x?.1:y` must continue to work.
*

​This is why I suggested a leading operator (`?a.?b()`) because it seems
like it would have the least potential for conflict with existing valid
syntax​

What about something like

MemberExpression[?Yield]  ? . IdentifierName
MemberExpression[?Yield]  ? *[* Expression[In, ?Yield] ]

Context specific to MemberExpressions, as far as I'm aware there's no
otherwise valid ternary expression that could be mixed up for it, and
it wouldn't need a cover grammar?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss