Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 25 août 2016 à 17:17, Claude Pache  a écrit :
> 
> 
>> Le 25 août 2016 à 16:05, Alexander Mekhonoshin > > a écrit :
>> 
>> 
>> 2. unary ?.
>> 
>> window?.navigator?.toString()
>> 
>> browser: "[object Navigator]"
>> node: ReferenceError: window is not defined
>> 
>> here i suggest syntax for exception-slient accesing globals:
>> 
>> ?.a === hostGlobalObject?.a
>> ?.a?.b === hostGlobalObject?.a?.b
> 
> For accessing the global object, I think that the current System.global 
> proposal is a better call, because it adds no syntax. See:
> 
> https://github.com/tc39/proposal-global 
> 
> 
> `System.global?.navigator.toString()` is somewhat lengthy, but it is 
> nevertheless simple and clear.
> 

Correction: `System.global.navigator?.toString()`


> —Claude


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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 25 août 2016 à 16:05, Alexander Mekhonoshin  a 
> écrit :
> 
> 
> 
> 3. groupped ?.()
> Syntax for the full existential chain case:
> 
> .?(a.b.c) // equals with typeof a !== 'undefined' && a.b && a.b.c
> 

In other words, `.?(a.b.c)` (or whatever other syntax) is approximately 
equivalent to `a?.b?.c`.

The advantage of such a shortcut should be weighted against the burden of 
learning yet another syntax. On that subject, I recommend to read:

https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 25 août 2016 à 16:05, Alexander Mekhonoshin  a 
> écrit :
> 
> 
> 2. unary ?.
> 
> window?.navigator?.toString()
> 
> browser: "[object Navigator]"
> node: ReferenceError: window is not defined
> 
> here i suggest syntax for exception-slient accesing globals:
> 
> ?.a === hostGlobalObject?.a
> ?.a?.b === hostGlobalObject?.a?.b

For accessing the global object, I think that the current System.global 
proposal is a better call, because it adds no syntax. See:

https://github.com/tc39/proposal-global

`System.global?.navigator.toString()` is somewhat lengthy, but it is 
nevertheless simple and clear.

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Alexander Mekhonoshin]

// Excuse my beginner’ English

I have a few (3) thoughts:


1. binary ?.
If a === null: a?.b.c === undefined

If a?.b === null: a?.b.c // throws exception

If a?.b === null: a?.b?.c === undefined

If a === 0: a?.b.c === undefined

If a === '': a?.b.c === undefined

If a in not defined: a?.b.c // throws exception

If a === undefined but defined: a?.b.c === undefined



2. unary ?.

window?.navigator?.toString()

browser: "[object Navigator]"
node: ReferenceError: window is not defined

here i suggest syntax for exception-slient accesing globals:

?.a === hostGlobalObject?.a
?.a?.b === hostGlobalObject?.a?.b


3. groupped ?.()
Syntax for the full existential chain case:

.?(a.b.c) // equals with typeof a !== 'undefined' && a.b && a.b.c

I use .? here too because ?:___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 8 févr. 2016 à 01:16, Bergi  a écrit :
> 
> Claude Pache wrote:
>> 
>>> .?
>>> (?)
>>> [?]
>> 
>> Yes, that syntax is possible. Whether it is preferable is a question of 
>> taste. Personally, I don’t like it:
>> 
>> * I slightly prefer `?.` over `.?` for the following reason: The `?.` token 
>> may be conceptually separated in two, first the question mark which checks 
>> whether the expression at its left evaluates to null/undefined (and orders 
>> to stop processing if it is the case); then the dot which proceeds with 
>> property lookup.
> 
> Totally agreed.
> 
>> * I find that the question mark inside the brackets is out of place, as it 
>> isn’t part of the arguments (for function call) or of the expression 
>> defining the key (for property access).
> 
> I agree here as well, it does feel out of place, and `?[…]`/`?(…)` would feel 
> a lot more natural. Given that those are not feasible for parsing however, I 
> would still prefer them
> 
> obj[?expr]
> func(? …args)
> new C(? …args)
> 
> over the proposed alternative
> 
> obj?.[expr]
> func?.(…args)
> new C?.(…args)
> 
> where the placement of the dot is just horrifying my eyes.

Personally, I'm less attached to aesthetics than legibility.

> Maybe we could at least use some other character instead of the dot?
> 
> obj?:[expr]
> func?:(…args)
> new C?:(…args)
> 
> might bear too much resemblance to the ternary, but imo the colon fits better 
> than the dot here.

Placing the colon before the interrogation mark might also work (at the 
condition we don’t intend to use `?` as a prefix operator):

```js
obj:?.prop // (not needed, for symmetry)
obj:?[expr]
func:?(...args)
```

—Claude

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 8 févr. 2016 à 19:58, John Lenz  a écrit :
> 
> If we ever hope to include "elvis".
> 
> obj?:[expr]
> 
> would be roughly equivalent to:
> 
> obj != null ? obj : [expr]
> 
> rather than what you are suggesting here:
> 
> obj != null ? obj[expr] : undefined;

We can always use `??` for that purpose, as do some languages.

However, using the same syntax as an operator (of other languages) with 
different semantics may be problematic.

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[John Lenz]

If we ever hope to include "elvis".

obj?:[expr]

would be roughly equivalent to:

obj != null ? obj : [expr]

rather than what you are suggesting here:

obj != null ? obj[expr] : undefined;


On Sun, Feb 7, 2016 at 4:16 PM, Bergi  wrote:

> Claude Pache wrote:
>
>>
>> .?
>>> (?)
>>> [?]
>>>
>>
>> Yes, that syntax is possible. Whether it is preferable is a question of
>> taste. Personally, I don’t like it:
>>
>> * I slightly prefer `?.` over `.?` for the following reason: The `?.`
>> token may be conceptually separated in two, first the question mark which
>> checks whether the expression at its left evaluates to null/undefined (and
>> orders to stop processing if it is the case); then the dot which proceeds
>> with property lookup.
>>
>
> Totally agreed.
>
> * I find that the question mark inside the brackets is out of place, as it
>> isn’t part of the arguments (for function call) or of the expression
>> defining the key (for property access).
>>
>
> I agree here as well, it does feel out of place, and `?[…]`/`?(…)` would
> feel a lot more natural. Given that those are not feasible for parsing
> however, I would still prefer them
>
> obj[?expr]
> func(? …args)
> new C(? …args)
>
> over the proposed alternative
>
> obj?.[expr]
> func?.(…args)
> new C?.(…args)
>
> where the placement of the dot is just horrifying my eyes.
> Maybe we could at least use some other character instead of the dot?
>
> obj?:[expr]
> func?:(…args)
> new C?:(…args)
>
> might bear too much resemblance to the ternary, but imo the colon fits
> better than the dot here.
>
> Regards,
>  Bergi
>
> ___
> 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: Optional Chaining (aka Existential Operator, Null Propagation)

[Bergi]

Claude Pache wrote:



.?
(?)
[?]


Yes, that syntax is possible. Whether it is preferable is a question of taste. 
Personally, I don’t like it:

* I slightly prefer `?.` over `.?` for the following reason: The `?.` token may 
be conceptually separated in two, first the question mark which checks whether 
the expression at its left evaluates to null/undefined (and orders to stop 
processing if it is the case); then the dot which proceeds with property lookup.


Totally agreed.


* I find that the question mark inside the brackets is out of place, as it 
isn’t part of the arguments (for function call) or of the expression defining 
the key (for property access).


I agree here as well, it does feel out of place, and `?[…]`/`?(…)` would 
feel a lot more natural. Given that those are not feasible for parsing 
however, I would still prefer them


obj[?expr]
func(? …args)
new C(? …args)

over the proposed alternative

obj?.[expr]
func?.(…args)
new C?.(…args)

where the placement of the dot is just horrifying my eyes.
Maybe we could at least use some other character instead of the dot?

obj?:[expr]
func?:(…args)
new C?:(…args)

might bear too much resemblance to the ternary, but imo the colon fits 
better than the dot here.


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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

>
> Yes: the `?.` operator does not change the meaning of the subsequent `.`
> operator. I like to think of it as: the effect is local (short-circuiting
> aside), you are not switching between "modes". It’s a feature.
>

Just curious:  what's the rationale for that behavior, as opposed to "deep"
short-circuiting?  It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Mat At Bread]

I'd also prefer this. Plus, one could use 'try' in an expression context as 
a unary operator.



// z is undefined if a or a.b or a.b.c are undefined
z = try a.b.c ;

// x is undefined if a exists but b or c don't. It throws a ReferenceError 
if a doesn't exist.

x = a.(try b.c) ;



I've not thought it through all the way, but an implementation would be an 
implicit catch that re-throws on anything that's not a ReferenceError, e.g.



x = a ;
try {
   x = x.b.c ;
} catch(ex) {
   if (!(ex instanceof ReferenceError))
   throw ex ;
}


_
Re: Optional Chaining (aka Existential Operator, Null Propagation)
From: Kevin Smith <zenpars...@gmail.com>
Date: 5 Feb, 15:22
To: Claude Pache <claude.pa...@gmail.com>
CC: es-discuss <es-discuss@mozilla.org>

Show quoted text


Just curious: what's the rationale for that behavior, as opposed to "deep"
short-circuiting? It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d



On 5 February 2016 5:08:38 p.m. es-discuss-requ...@mozilla.org 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: Optional Chaining (aka Existential Operator, Null
  Propagation) (Kevin Smith)
   2. January 26th 2016 Meeting Notes (Rick Waldron)



--
Re: Optional Chaining (aka Existential Operator, Null Propagation)
From: Kevin Smith <zenpars...@gmail.com>
Date: 5 Feb, 15:22
To: Claude Pache <claude.pa...@gmail.com>
CC: es-discuss <es-discuss@mozilla.org>



Yes: the `?.` operator does not change the meaning of the subsequent `.`
operator. I like to think of it as: the effect is local (short-circuiting
aside), you are not switching between "modes". It’s a feature.



Just curious:  what's the rationale for that behavior, as opposed to "deep"
short-circuiting?  It seems like if I have a long query, like:

a.b.c.d

I think I would typically want to test that the whole query is satisfiable
(not just a single term), so I'll need to write:

a?.b?.c?.d



--
January 26th 2016 Meeting Notes
From: Rick Waldron <waldron.r...@gmail.com>
Date: 5 Feb, 17:08
To: es-discuss <es-discuss@mozilla.org>

January 26th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter
Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Leland Richardson
(LM), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave
Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel
Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS),
John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar
Horwat (WH), Mark S. Miller (MM), Paul Leathers (PL), Sebastian Markbage
(SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith
Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin
Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick
Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)


## Agenda

https://github.com/tc39/agendas/blob/master/2016/01.md


## Approval of the minutes from November 2015

WH: what sort of changes?

JHD: some editorial cleanup

 Conclusion/Resolution

  - Minutes approved.



## 5. Proposals for Future Editions

## 5.i Zones

DD: Misko is presenting, zones.

https://docs.google.com/presentation/d/1H3E2ToJ8VHgZS8eS6bRv-vg5OksObj5wv6gyzJJwOK0/edit#slide=id.p

MH: Writing async code is hard, specifically book keeping of (begin/end of
async tasks). Specifically for framework authoring, and cooperation between
various components. In other langauges, this may be "domains" or "contexts".

MH: some existing implementations, Angular Zone.js, Zone, Dart Zones,
Node.js domains/continuation local storage/asyncwrap, c# logical call
context etc.

MH: this has been around for some time, but the lack of standarization
prevents interopt and may also prevent more ideal solutions.

MH: Frameworks often what to know when work has begun and completing, this
allows for batching.

WH: Can you clarify the example?

MH: In a typcial application, a whole orchistration of async tasks occurs

YK: browser do this already, flush work -> calculate changes -> paint.

MH: by annotating different context, prioritizaing is possible. One example
would be animation context vs ..

WH: thanks

MH: another example is testing, exist

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 5 févr. 2016 à 16:22, Kevin Smith  a écrit :
> 
> Yes: the `?.` operator does not change the meaning of the subsequent `.` 
> operator. I like to think of it as: the effect is local (short-circuiting 
> aside), you are not switching between "modes". It’s a feature.
> 
> Just curious:  what's the rationale for that behavior, as opposed to "deep" 
> short-circuiting?  It seems like if I have a long query, like:
> 
> a.b.c.d
> 
> I think I would typically want to test that the whole query is satisfiable 
> (not just a single term), so I'll need to write:
> 
> a?.b?.c?.d
> 


(In order to avoid confusion from those that read casually that thread, I 
recall that the proposal already features "long" short-circuiting in the sense 
that the end point of the short-circuiting jump is the end of the entire chain 
of property accesses, method calls, etc. The issue here is essentially whether 
a `?.` should implicitly transform all subsequent `.` in the chain into `?.`.)

The general rationale is, as I've said, no modes, because modes are confusing. 
In the particular case, there should be testimonies that the pattern 
`a?.b?.c?.d` is both sufficiently common and annoying in order to consider an 
exception to that rule.

But here is a random example, where I would not use stacked `?.` or something 
semantically equivalent:

```js
var numberOfSelectedItems = 
myForm.querySelector('select[name=foo]')?.selectedOptions.length || 0;
```

In case `myForm.querySelector('select[name=foo]')` is not null, then 
`myForm.querySelector('select[name=foo]').selectedOptions` is always an 
HTMLCollection and has always a `length` property. If it is not the case, then 
either I made a typo, or I am testing some ancient browser that doesn’t support 
yet the `selectedOptions` property. In both cases, I want an exception to be 
thrown rather than an error to be dropped: it's easier to debug.

—Claude


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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

>
> In case `myForm.querySelector('select[name=foo]')` is not null, then
> `myForm.querySelector('select[name=foo]').selectedOptions` is always an
> HTMLCollection and has always a `length` property. If it is not the case,
> then either I made a typo, or I am testing some ancient browser that
> doesn’t support yet the `selectedOptions` property. In both cases, I want
> an exception to be thrown rather than an error to be dropped: it's easier
> to debug.
>

Makes sense, thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 4 févr. 2016 à 21:03, Kevin Smith  a écrit :
> 
> (...)  The syntax still seems problematic, though, from an aesthetic point of 
> view.
> 
> The `obj ?. prop` form looks natural and aligns well with how this feature 
> appears in other languages.  The other forms are less natural:
> 
> obj?.[expr] 
> func?.(...args)
> new C?.(...args)
> 
> I'm not particularly convinced by any of the other syntactic variants we've 
> seen.

Yeah, I fear that we couldn’t find a "good" syntax for those, given that  
`obj?[expr]` and `func?(...args)` are most probably excluded  :-(

```js
o.x?[y]+z // should be parsed as:  (o.x?[y]) + z
o.x?[y]+z:t   // should be parsed as:  o.x ? ([y] + z) : t
```

—Claude

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 4 févr. 2016 à 21:03, Kevin Smith  a écrit :
> 
> 
> That aside, I have a question about the semantics.  What does this do:
> 
> ({ x: 1 }).x?.y.z;
> 
> Does it throw a ReferenceError?
> 

Yes: the `?.` operator does not change the meaning of the subsequent `.` 
operator. I like to think of it as: the effect is local (short-circuiting 
aside), you are not switching between "modes". It’s a feature.

Maybe I should write a desugaring in my proposal. The expression `({ x: 1 
}).x?.y.z` is equivalent to:

```
(function () {
var $1 = { x: 1 }).x;
if ($1 == null)
return undefined;
return $1.y.z;
})()
```

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[John Lenz]

On Wed, Feb 3, 2016 at 2:41 PM, Claude Pache  wrote:

>
> > Le 3 févr. 2016 à 20:56, John Lenz  a écrit :
> >
> > Can you reference something as to why the more obvious operators are
> problematic?
> >
> > ?.
>
> That one (that I've used) must work, with the simple lookahead I've put in
> the lexical grammar, in order to continue to parse `x?.3:0` as today.
>
> > ?[]
> > ?()
>
> For those it is difficult for the parser to easily (i.e. quickly, without
> trying and backtracking code of arbitrary length) distinguish from the
> conditional operator, as in: `x ?(y - 2) + 3 : 0` Also, the difference of
> precedence level between the two operators makes the use of a cover grammar
> (I think) impossible.
>

Waldemar's example makes the problem obvious but I think we could do use,
which I think is preferable to the proposed:

.?
(?)
[?]



>
> > ?:
>
> I'm not sure what that one should be used for. (If you mean the Elvis
> operator, it's out of the scope of the proposal.
>

yes, I meant the equivalent to:

x ?: value
x == null ? x : value



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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[/#!/JoePea]

Hello Claude, you prefer `?.` over `.?` as an implementor (I understand
what you said about the parsing). But I think as and end user of the
syntax, `.?` over `?.` makes more sense as it is easier to distinguish from
the ternary operator with a float, as in `x?.3:0` (we know a numerical key
can't be accessed with the dot operator currently) and `x?.foo:0`. If we
assume the existential operator doesn't allow numerical property access,
then `x.?3` is *obviously* an error (not so obvious with `?.`), and we
won't expect the ternary operator. Although, `x.?3` also introduces the
interesting possibility of allowing numerical property access as that also
can't be confused with a float-in-a-ternary like `x?.3` can, which would
mean that with `x.?3` we would not need to use `[]` to access numerical
properties (which be convenient in the use case of the existential
operator!). Something like `x.?.3` would have to fail as a syntax error.

```
let a = [1,2,{n:1}]
console.log(a[2]) // {n:1}
console.log(a.?2) // {n:1}
console.log(a.?.2) // SyntaxError
console.log(a.?2.3) // SyntaxError: Unexpected number (the 3)
console.log(a.?2.n) // 1
console.log(a.?2.?n) // 1
```

/#!/JoePea
On Feb 4, 2016 10:06 AM, "Claude Pache"  wrote:

>
> Le 4 févr. 2016 à 17:47, John Lenz  a écrit :
>
>
> [...]
>
>
> Waldemar's example makes the problem obvious but I think we could do use,
> which I think is preferable to the proposed:
>
> .?
> (?)
> [?]
>
>
> Yes, that syntax is possible. Whether it is preferable is a question of
> taste. Personally, I don’t like it:
>
> * I slightly prefer `?.` over `.?` for the following reason: The `?.`
> token may be conceptually separated in two, first the question mark which
> checks whether the expression at its left evaluates to null/undefined (and
> orders to stop processing if it is the case); then the dot which proceeds
> with property lookup.
>
> * I find that the question mark inside the brackets is out of place, as it
> isn’t part of the arguments (for function call) or of the expression
> defining the key (for property access).
>
>
>
>> [...]
>
>
> yes, I meant the equivalent to:
>
> x ?: value
> x == null ? x : value
>
>
> I assume you meant: `x != null ? x : value`
>
> Note that this is a completely different operator. For the proposed
> optional chaining operator, we stop processing when the LHS is
> null/undefined; while for the `?:` null-coalescing operator, it is the
> other way round. Also, the precedence is not the same.
>
> I have wilfully restricted the scope of my proposal to optional chaining
> only, because of its intrinsic technical complexity.
>
> —Claude
>
> ___
> 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: Optional Chaining (aka Existential Operator, Null Propagation)

[John Lenz]

On Thu, Feb 4, 2016 at 10:06 AM, Claude Pache 
wrote:

>
> Le 4 févr. 2016 à 17:47, John Lenz  a écrit :
>
>
> [...]
>
>
> Waldemar's example makes the problem obvious but I think we could do use,
> which I think is preferable to the proposed:
>
> .?
> (?)
> [?]
>
>
> Yes, that syntax is possible. Whether it is preferable is a question of
> taste. Personally, I don’t like it:
>
> * I slightly prefer `?.` over `.?` for the following reason: The `?.`
> token may be conceptually separated in two, first the question mark which
> checks whether the expression at its left evaluates to null/undefined (and
> orders to stop processing if it is the case); then the dot which proceeds
> with property lookup.
>
>
* I find that the question mark inside the brackets is out of place, as it
> isn’t part of the arguments (for function call) or of the expression
> defining the key (for property access).
>

I agree with this but I think I would get used to ".?", etc.   "?.(" and
"?.[" are awkward, and longer (and harder to type).  ".?" "(?" and "[?"
would parse easily, are short


>
>
>
>> [...]
>
>
> yes, I meant the equivalent to:
>
> x ?: value
> x == null ? x : value
>
>
> I assume you meant: `x != null ? x : value`
>

haha, yes


>
>

> Note that this is a completely different operator. For the proposed
> optional chaining operator, we stop processing when the LHS is
> null/undefined; while for the `?:` null-coalescing operator, it is the
> other way round. Also, the precedence is not the same.
>
> I have wilfully restricted the scope of my proposal to optional chaining
> only, because of its intrinsic technical complexity.
>

sure.  that is very reasonable.


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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 4 févr. 2016 à 17:47, John Lenz  a écrit :
> 
> 
> [...]
> 
> Waldemar's example makes the problem obvious but I think we could do use, 
> which I think is preferable to the proposed:
> 
> .?
> (?)
> [?]

Yes, that syntax is possible. Whether it is preferable is a question of taste. 
Personally, I don’t like it:

* I slightly prefer `?.` over `.?` for the following reason: The `?.` token may 
be conceptually separated in two, first the question mark which checks whether 
the expression at its left evaluates to null/undefined (and orders to stop 
processing if it is the case); then the dot which proceeds with property lookup.

* I find that the question mark inside the brackets is out of place, as it 
isn’t part of the arguments (for function call) or of the expression defining 
the key (for property access).

>  
> [...]
>  
> yes, I meant the equivalent to:
> 
> x ?: value
> x == null ? x : value

I assume you meant: `x != null ? x : value`

Note that this is a completely different operator. For the proposed optional 
chaining operator, we stop processing when the LHS is null/undefined; while for 
the `?:` null-coalescing operator, it is the other way round. Also, the 
precedence is not the same.

I have wilfully restricted the scope of my proposal to optional chaining only, 
because of its intrinsic technical complexity.

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Kevin Smith]

Thanks for putting this together.  At first glance, I think the semantics
look pretty good.  The syntax still seems problematic, though, from an
aesthetic point of view.

The `obj ?. prop` form looks natural and aligns well with how this feature
appears in other languages.  The other forms are less natural:

obj?.[expr]
func?.(...args)
new C?.(...args)

I'm not particularly convinced by any of the other syntactic variants we've
seen.

That aside, I have a question about the semantics.  What does this do:

({ x: 1 }).x?.y.z;

Does it throw a ReferenceError?

In general, when this feature is used in other languages, do you tend to
see the optional operator stacked up for the rest of the member expression?
E.g.

obj.a?.b?.c?.d

In order to avoid reference errors "in the middle"?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Waldemar Horwat]

On 02/03/2016 11:56, John Lenz wrote:

Can you reference something as to why the more obvious operators are 
problematic?

?.
?[]
?()
?:


Some of these have problems.  For example, a?[]:b is already valid ECMAScript 
syntax and does something else.  There is an analogous but subtler problem for 
a?(.

Waldemar

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

> Le 3 févr. 2016 à 20:56, John Lenz  a écrit :
> 
> Can you reference something as to why the more obvious operators are 
> problematic?
> 
> ?.

That one (that I've used) must work, with the simple lookahead I've put in the 
lexical grammar, in order to continue to parse `x?.3:0` as today. 

> ?[]
> ?()

For those it is difficult for the parser to easily (i.e. quickly, without 
trying and backtracking code of arbitrary length) distinguish from the 
conditional operator, as in: `x ?(y - 2) + 3 : 0` Also, the difference of 
precedence level between the two operators makes the use of a cover grammar (I 
think) impossible.

> ?:

I'm not sure what that one should be used for. (If you mean the Elvis operator, 
it's out of the scope of the proposal.)

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

Re: Optional Chaining (aka Existential Operator, Null Propagation)

[John Lenz]

Can you reference something as to why the more obvious operators are
problematic?

?.
?[]
?()
?:

On Fri, Jan 29, 2016 at 7:19 AM, Claude Pache 
wrote:

> Hi,
>
> I have prepared a strawman for the `?.` operator:
>
> https://github.com/claudepache/es-optional-chaining/
>
> If there is interest in that proposal, I'm looking for a champion from
> TC39.
>
> Regards,
>
> —Claude
>
> ___
> 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

Optional Chaining (aka Existential Operator, Null Propagation)

[Claude Pache]

Hi,

I have prepared a strawman for the `?.` operator:

https://github.com/claudepache/es-optional-chaining/ 


If there is interest in that proposal, I'm looking for a champion from TC39.

Regards,

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