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 <sanderd17 at gmail.com>
wrote:

>
>
> 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei <alonecomp at gmail.com>:
>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/09f7019d/attachment.html>

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 ,
Laurenţiu Macovei

On Thu, Oct 29, 2015 at 7:29 PM, Sander Deryckere <sanderd17 at gmail.com>

wrote: