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: Existential Operator / Null Propagation Operator

[Waldemar Horwat]

On 10/29/2015 12:19, Laurentiu Macovei wrote:

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


No.  It would break existing code:

  x = foo?.3:.5;

  x = foo?[a]:[b];

On the other hand, turning .. into a token should be fine.

Waldemar

___
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: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

[Steve Fink]

Uh, isn't that a pretty large compatibility risk?



You're suddenly calling doUntestedStuff() where before it was harmlessly 
erroring.



On 10/29/2015 12: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
```

On Fri, 30 Oct 2015, 06:07  > wrote:



-- Forwarded message --
From: Laurentiu Macovei >
To: Sander Deryckere >
Cc: "es-discuss@ mozilla.org
 list" >
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
://
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: Existential Operator / Null Propagation Operator

[Claude Pache]

> Le 29 oct. 2015 à 19:32, Eli Perelman  a écrit :
> 
> 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

Treating `..` as one token would be a breaking change, but I don't think it is 
a problem in practice, as `3..toString()` would continue to work. In some cases 
– as in `3..toStrign()` –, `undefined` will be produced where an error was 
thrown.

—Claude

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

Re: Existential Operator / Null Propagation Operator

[Isiah Meadows]

1. `foo?.3:.5` should be unambiguously `foo ? 0.3 : 0.5`, because `3` is a
number, not an identifier. `foo?.3` in any other context should be a syntax
error. It's also inconsistent with array access otherwise.
2. I wouldn't have a problem with `object?.[prop]`, since that's only one
character more. It's still a lot easier.

On Thu, Oct 29, 2015, 18:00 Claude Pache  wrote:

>
>
> >> Le 29 oct. 2015 à 21:04, Waldemar Horwat  a écrit
> :
> >>
> >> On 10/29/2015 12:19, Laurentiu Macovei wrote:
> >>  `foo?.bar` and `foo?['bar']` syntax would work too.
> >
> > No.  It would break existing code:
> >
> >  x = foo?.3:.5;
>
> That could be resolved by a simple lookahead, I think.
> >
> >  x = foo?[a]:[b];
>
> That one is more problematic. IIRC, it was once suggested to use`?.[`
> instead.
>
> —Claude
>
> >
> > On the other hand, turning .. into a token should be fine.
> >
> >Waldemar
> >
> > ___
> > 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: Existential Operator / Null Propagation Operator

[Waldemar Horwat]

On 10/29/2015 14:20, Claude Pache wrote:



Le 29 oct. 2015 à 19:32, Eli Perelman  a écrit :

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


Treating `..` as one token would be a breaking change,


Exactly what existing code would it break?


but I don't think it is a problem in practice, as `3..toString()` would 
continue to work.


It would continue to work for the trivial reason that `3..toString()` doesn't 
contain a .. token.  It's the number 3. followed by a . and then an identifier 
and parentheses.

This is no different from 3.e+2 not containing a + token.

 In some cases – as in `3..toStrign()` –, `undefined` will be produced where an 
error was thrown.

No, this would continue to throw an error.

Waldemar

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

Re: Existential Operator / Null Propagation Operator

[Claude Pache]

>> Le 29 oct. 2015 à 21:04, Waldemar Horwat  a écrit :
>> 
>> On 10/29/2015 12:19, Laurentiu Macovei wrote:
>>  `foo?.bar` and `foo?['bar']` syntax would work too.
> 
> No.  It would break existing code:
> 
>  x = foo?.3:.5;

That could be resolved by a simple lookahead, I think. 
> 
>  x = foo?[a]:[b];

That one is more problematic. IIRC, it was once suggested to use`?.[` instead. 

—Claude 

> 
> On the other hand, turning .. into a token should be fine.
> 
>Waldemar
> 
> ___
> 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: Map literal

[Isiah Meadows]

Why not make it desugar to a direct function call with a single array of
pairs? It's so parsed as a regular object, so shorthands can still be used.

`Map#{foo: 1, bar: 2, 3: "baz"}`
`Map[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`

`Object#{foo: 1, bar: 2, 3: "baz"}`
`Object[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`

`Object.null#{foo: 1, bar: 2, 3: "baz"}`
`Object.null[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`

(`bar` doesn't have [[Construct]])
`Object#{foo, bar() {}}`
`Object[Symbol.fromHash]([[foo", foo], ["bar", function () {}]])`

And as for implementation, use this:

```js
extend class Map {
  static [Symbol.fromHash](pairs) {
return new this(pairs);
  }
}

// etc...

function SetKeys(target, pairs) {
  for (const [key, value] of pairs) {
  target[key] = value
}
return target
}

extend class Object {
  static [Symbol.fromHash](pairs) {
return SetKeys({}, pairs)
  }

  static null(pairs) {
return SetKeys(Object.create(null), pairs)
  }
}
```

Pretty simple IMHO. A helper decorator could even be made.

On Wed, Oct 28, 2015, 14:34 Alexander Jones  wrote:

> Also I would like to reiterate that errors in the shape of the N-by-2
> array are only caught at runtime. That's really not ideal.
>
> On Wednesday, 28 October 2015, Dave Porter  wrote:
>
>> I don’t love any of the specific suggestions so far, but saving 3 + 2n
>> keystrokes isn't the point – readability and learnability are. Visually,
>> `new Map([[‘foo’, 42]])` is a mess.
>>
>> On Oct 28, 2015, at 9:28 AM, Michał Wadas  wrote:
>>
>> Difference between any proposed here syntax and current state ( new Map([
>> [1,2], [2,3] ]); ) is..
>>
>> 3 characters + 2 characters/entry.
>>
>>
>>
>>
>> 2015-10-28 17:22 GMT+01:00 Mohsen Azimi :
>>
>>> When I look at `Map#{"foo": 42}` I don't see much difference with `new
>>> Map([['foo', 42]])`.
>>>
>>> Since you can pass expressions there, it's already possible to do it
>>> with current syntax. There is only a bunch of extra brackets(`[` and `]`)
>>> that I don't like.
>>>
>>>
>>> On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones  wrote:
>>>
 Ah, there is actually a good case for keeping barewords in object
 literals but removing them from map literals, and that's due to objects
 accessing string properties as bare words, too. This is almost never the
 case for other map types.

 ```
 const o = {foo: 42};
 o.foo === 42;
 o.bar = 43;

 const m = Map#{"foo": 42};
 m.get("foo") === 42;
 m.set("bar", 43);
 ```

 Would you agree?


 On Wednesday, 28 October 2015, Alexander Jones  wrote:

> Hi Herby
>
> Agree with your concerns about symmetry with object literals, but many
> of the uses of maps benefit from having non string keys, and in such case
> generally everything would involve wrapping in []. Trying to use an Array
> as a key would be quite ugly with the extra squares required
>
> ```
> const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}
> vs
> const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}
> ```
>
> Perhaps a middle ground could be that if you want to use an expression
> that would otherwise be a bare word, you enclose in parens. The visual
> binding of the colon is deceptive anyway, so I tend to do this if the key
> expression contains a space:
>
> ```
> MyMap#{1 + 2 + 3: 6}
> vs.
> MyMap#{(1 + 2 + 3): 6}
> ```
>
> But I think I still prefer that the parsing for the key part is just
> standard expression evaluation, personally, and the POJSO literal 
> barewords
> remain the only special case.
>
> Indeed,
>
> ```
> Object#{1: "one", Symbol(): "sym"}
> ```
>
> Could Object-key-ify the keys, i.e. turn them into strings if not
> symbols, and Just Work (but a default implementation on the Object
> prototype is questionable!). That said I'm not sure we should be using
> Object for this kind of thing. At this point I don't know what a raw
> `#{}` should produce... There may be a better use case for it in the
> future, horrible ASI complexities notwithstanding.
>
> Alex
>
>
> On Wednesday, 28 October 2015, Herby Vojčík  wrote:
>
>>
>>
>> Alexander Jones wrote:
>>
>>> Ok, thanks for clarifying. Not only does it preserve order but it
>>> also
>>> permits non-string keys. You're still missing one detail which is
>>> that
>>> `bar` would actually be a variable not a string key.
>>>
>>> Another example to clarify that the key part would be an expression:
>>>
>>> ```
>>> Map#{foo(42) + 7: "bar"}
>>> ```
>>>
>>> I prefer this over the precedent set by object literals which would
>>> require 

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  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   wrote:
>
>
> -- Forwarded message --
> From: Laurentiu Macovei 
> To: Sander Deryckere 
> Cc: "es-discuss@ mozilla.org
>  list" 
> 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
> ://
> 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: Existential Operator / Null Propagation Operator

[Claude Pache]

> Le 30 oct. 2015 à 00:07, Waldemar Horwat  a écrit :
> 
>> On 10/29/2015 14:20, Claude Pache wrote:
> 
>> In some cases – as in `3..toStrign()` –, `undefined` will be produced where 
>> an error was thrown.
> 
> 
> No, this would continue to throw an error.

Oops, you're right. So, `..` is 100% backward-compatible. 

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

Re: Map literal

[Alexander Jones]

I don't think borrowing object notation is a good idea. What exactly does

```
const myMap = Map#{
get foo() { return 100; },
set foo(v) {}
constructor() {}
};
```

mean?

Honestly, a very significant portion of the use cases I have for *actual
maps* don't involve string keys. So to borrow object notation and have to
constantly write keys in [] is pretty naff:

```
const describe = Dict#{
[1]: "one",
[[1, 2]]: "array of 1 and 2",
[null]: "the null value",
}; // please no!
```

If it makes people feel too weird to have comma separated, colon split
key-value pairs within curlies that *don't* parse like POJSOs, we could
have completely non-ambiguous parse with normal parentheses, I think?

```
const describe = Dict#(
1: "one",
[1, 2]: "array of 1 and 2",
null: "the null value",
);
```

That might limit confusion while giving a syntactically clean way to define
maps. Let's consider that a future mapping type like Dict compares
non-primitive keys by abstract value instead of by reference identity.
There are *tonnes* of nice use cases that open up that are taken for
granted in other languages and other classes like Immutable.Map - we're not
there yet with ES6 built-ins, so perhaps people might not yet appreciate
the value of this.

To reiterate a previous point, object property access with a statically
defined string key is idiomatically written `obj.foo`, so it makes sense
for symmetry to have `foo` appear as a bareword in a literal defining `obj
= {foo: 42}`. For most mapping-type classes this symmetry simply does not
apply, and frankly neither should it.

Also, I specifically suggested that the consumed value is an ArrayIterator
rather than an Array, because I feel having an intermediate Array around is
placing too high an importance on the humble Array. If the implementation
really wants an Array to work on internally, they can simply call
`Array.from` with little cost. But if they want an Immutable.List they can
have that instead without ever seeing an actual Array. (The Symbol.fromHash
method is just Symbol.literalOf as I called it - same thing, modulo
bikeshed.)

Alex


On 29 October 2015 at 22:51, Isiah Meadows  wrote:

> Why not make it desugar to a direct function call with a single array of
> pairs? It's so parsed as a regular object, so shorthands can still be used.
>
> `Map#{foo: 1, bar: 2, 3: "baz"}`
> `Map[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> `Object#{foo: 1, bar: 2, 3: "baz"}`
> `Object[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> `Object.null#{foo: 1, bar: 2, 3: "baz"}`
> `Object.null[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`
>
> (`bar` doesn't have [[Construct]])
> `Object#{foo, bar() {}}`
> `Object[Symbol.fromHash]([[foo", foo], ["bar", function () {}]])`
>
> And as for implementation, use this:
>
> ```js
> extend class Map {
>   static [Symbol.fromHash](pairs) {
> return new this(pairs);
>   }
> }
>
> // etc...
>
> function SetKeys(target, pairs) {
>   for (const [key, value] of pairs) {
>   target[key] = value
> }
> return target
> }
>
> extend class Object {
>   static [Symbol.fromHash](pairs) {
> return SetKeys({}, pairs)
>   }
>
>   static null(pairs) {
> return SetKeys(Object.create(null), pairs)
>   }
> }
> ```
>
> Pretty simple IMHO. A helper decorator could even be made.
>
> On Wed, Oct 28, 2015, 14:34 Alexander Jones  wrote:
>
>> Also I would like to reiterate that errors in the shape of the N-by-2
>> array are only caught at runtime. That's really not ideal.
>>
>> On Wednesday, 28 October 2015, Dave Porter 
>> wrote:
>>
>>> I don’t love any of the specific suggestions so far, but saving 3 + 2n
>>> keystrokes isn't the point – readability and learnability are. Visually,
>>> `new Map([[‘foo’, 42]])` is a mess.
>>>
>>> On Oct 28, 2015, at 9:28 AM, Michał Wadas  wrote:
>>>
>>> Difference between any proposed here syntax and current state ( new
>>> Map([ [1,2], [2,3] ]); ) is..
>>>
>>> 3 characters + 2 characters/entry.
>>>
>>>
>>>
>>>
>>> 2015-10-28 17:22 GMT+01:00 Mohsen Azimi :
>>>
 When I look at `Map#{"foo": 42}` I don't see much difference with `new
 Map([['foo', 42]])`.

 Since you can pass expressions there, it's already possible to do it
 with current syntax. There is only a bunch of extra brackets(`[` and `]`)
 that I don't like.


 On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones  wrote:

> Ah, there is actually a good case for keeping barewords in object
> literals but removing them from map literals, and that's due to objects
> accessing string properties as bare words, too. This is almost never the
> case for other map types.
>
> ```
> const o = {foo: 42};
> o.foo === 42;
> o.bar = 43;
>
> const m = Map#{"foo": 42};
> m.get("foo") === 42;
> m.set("bar", 43);

Re: Existential Operator / Null Propagation Operator

[Ron Waldon]

Yep. I agree now. I see that this would break loads of existing code.
Thanks.

On Fri, 30 Oct 2015, 12:23   wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https ://
mail.mozilla.org
/
listinfo
/
es-discuss

or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."
Today's Topics:

   1. Re: Re: Existential Operator / Null Propagation Operator
  (LaurentiuMacovei) (Isiah Meadows)
   2. Re: Existential Operator / Null Propagation Operator
  (Waldemar Horwat)
   3. Re: Existential Operator / Null Propagation Operator
  (Claude Pache)
   4. Re: Map literal (Alexander Jones)

-- Forwarded message --
From: Isiah Meadows 
To: Ron Waldon , es-discuss@mozilla.org
Cc:
Date: Thu, 29 Oct 2015 23:03:28 +
Subject: Re: Re: Existential Operator / Null Propagation Operator
(Laurentiu Macovei)

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  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