Existential Operator / Null Propagation Operator (original) (raw)

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39:Microsoft/TypeScript#16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?
short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1 but we'd be happy to build a reference implementation for option #2.

I recall that another issue was that of transitivity. Right now, (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be equivalent expressions. I think we need some input from the people on this list about whether this is okay or why we value transitivity for this operator.

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?()which would conditionally invoke fn.

esprima-fb change: cpojer/esprima/tree/existential-operatorjstransform change:yungsters/jstransform/tree/existential-operator

Previous discussions on es-discuss:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?
short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1 but we'd be happy to build a reference implementation for option #2.

esprima-fb change: https://github.com/cpojer/esprima/tree/existential-operator jstransform change: https://github.com/yungsters/jstransform/tree/existential-operator

Previous discussions on es-discuss:

-- Christoph Pojer http://cpojer.net

Christoph Pojer wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39:Microsoft/TypeScript#16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

I liked the result of using a Null Pattern inside and materializing it outside, which once seemed to be plausible, with that a?.b.c would bevoid 0 of course. I don't remember on what it all died back then (yes, I have a bias, I wanted a true null pattern, AWB than said it is good inside but not really good as first class person).

Christoph Pojer wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39: https://github.com/Microsoft/TypeScript/issues/16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

I liked the result of using a Null Pattern inside and materializing it outside, which once seemed to be plausible, with that a?.b.c would be void 0 of course. I don't remember on what it all died back then (yes, I have a bias, I wanted a true null pattern, AWB than said it is good inside but not really good as first class person).

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1 but we'd be happy to build a reference implementation for option #2.

I recall that another issue was that of transitivity. Right now, (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be equivalent expressions. I think we need some input from the people on this list about whether this is okay or why we value transitivity for this operator.

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?() which would conditionally invoke fn.

esprima-fb change: https://github.com/cpojer/esprima/tree/existential-operator jstransform change: https://github.com/yungsters/jstransform/tree/existential-operator

Previous discussions on es-discuss:

https://esdiscuss.org/topic/the-existential-operator

https://esdiscuss.org/topic/specifying-the-existential-operator-using-abrupt-completion

https://esdiscuss.org/topic/sept-18-tc39-meeting-notes

Wouldn't option 1 provide the transitivity you're discussing? If a?.b.ccalls (void 0).c then (a?.b).c and a?.b.c would be identical, and both throw a TypeError.

From my reading, it seems like option 2 is the one that does not provide

transitivity, and tbh would surprise me greatly in the context of JS. If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Wouldn't option 1 provide the transitivity you're discussing? If a?.b.c calls (void 0).c then (a?.b).c and a?.b.c would be identical, and both throw a TypeError.

From my reading, it seems like option 2 is the one that does not provide transitivity, and tbh would surprise me greatly in the context of JS. If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

On Mon, Apr 6, 2015 at 11:40 AM, Herby Vojčík wrote:

Christoph Pojer wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39: https://github.com/Microsoft/TypeScript/issues/16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

I liked the result of using a Null Pattern inside and materializing it outside, which once seemed to be plausible, with that a?.b.c would be void 0 of course. I don't remember on what it all died back then (yes, I have a bias, I wanted a true null pattern, AWB than said it is good inside but not really good as first class person).

It appears that C# chose option #2 whereas Hack and CoffeeScript chose

option #1. Our current implementation chose option #1 but we'd be happy to build a reference implementation for option #2.

I recall that another issue was that of transitivity. Right now, (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be equivalent expressions. I think we need some input from the people on this list about whether this is okay or why we value transitivity for this operator.

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?() which would conditionally invoke fn.

esprima-fb change: https://github.com/cpojer/esprima/tree/existential- operator jstransform change: https://github.com/yungsters/jstransform/tree/existential-operator

Previous discussions on es-discuss:

https://esdiscuss.org/topic/the-existential-operator

https://esdiscuss.org/topic/specifying-the-existential- operator-using-abrupt-completion

https://esdiscuss.org/topic/sept-18-tc39-meeting-notes

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/04a1265a/attachment-0001.html

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?()which would conditionally invoke fn.

In the meeting notes you linked to, Waldemar (WH) noted that some of these variations may have grammar issues.

Although not strictly ambiguous with conditional expressions, fn ? ()would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

(Thanks for compiling the list of previous threads BTW).

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?() which would conditionally invoke fn.

In the meeting notes you linked to, Waldemar (WH) noted that some of these variations may have grammar issues.

Although not strictly ambiguous with conditional expressions, fn ? () would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

(Thanks for compiling the list of previous threads BTW). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/3bf6cd38/attachment.html

I hacked together something similar myself. IIRC, this particular transformation has issues with nested operators (e.g. a.b?.c.d?.e.f?.h). Of course that's an implementation detail, but the problem (if I'm remembering it right) is that people couldn't figure out what the implementation constraints are (I think there was consensus that the trinary transformation was unworkable), and without knowing those constraints it wasn't possible to write a spec for it.

I could be remembering all this wrong, but that's my recollection of how that conversation went. I think the consensus was to wait for the ? operator to become more mature in other languages.

On Mon, Apr 6, 2015 at 12:19 PM, Kevin Smith wrote:

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?() which would conditionally invoke fn.

In the meeting notes you linked to, Waldemar (WH) noted that some of these variations may have grammar issues.

Although not strictly ambiguous with conditional expressions, fn ? () would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

(Thanks for compiling the list of previous threads BTW).

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/5fd730d2/attachment.html

On Mon, Apr 6, 2015 at 3:19 PM, Kevin Smith <zenparsing at gmail.com> wrote:

Although not strictly ambiguous with conditional expressions, fn ? ()would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

I have two thoughts:

Could the language allow for a prefix operator instead (AKA 'The Maybe Operator'):?a.b and ?obj() and ?obj[Symbol.iterator]
You could make the postfix operator ?. which would be ugly but dodge the above issues:obj?.() and obj?.[Symbol.iterator]

Matthew Robb

On Mon, Apr 6, 2015 at 3:19 PM, Kevin Smith wrote:

Although not strictly ambiguous with conditional expressions, fn ? () would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

I have two thoughts:

Could the language allow for a prefix operator instead (AKA 'The Maybe Operator'): ?a.b and ?obj() and ?obj[Symbol.iterator]
You could make the postfix operator ?. which would be ugly but dodge the above issues: obj?.() and obj?.[Symbol.iterator]

Matthew Robb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/5fb40ac6/attachment.html

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

COND_DOT then became simply another binary operator in the Expression production.

However, this is a very simple use case. Supporting e.g. function calls would require more tokens (which raises the question: why stop at '.'? Should we have arithmetic versions too?). Given the proliferation of binary operator tokens in JS, I'm not sure if this is a good thing.

Joe

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

COND_DOT then became simply another binary operator in the Expression production.

Joe

On Mon, Apr 6, 2015 at 12:45 PM, joe wrote:

I hacked together something similar myself. IIRC, this particular transformation has issues with nested operators (e.g. a.b?.c.d?.e.f?.h). Of course that's an implementation detail, but the problem (if I'm remembering it right) is that people couldn't figure out what the implementation constraints are (I think there was consensus that the trinary transformation was unworkable), and without knowing those constraints it wasn't possible to write a spec for it.

I could be remembering all this wrong, but that's my recollection of how that conversation went. I think the consensus was to wait for the ? operator to become more mature in other languages.

On Mon, Apr 6, 2015 at 12:19 PM, Kevin Smith wrote:

If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: fn?() which would conditionally invoke fn.

In the meeting notes you linked to, Waldemar (WH) noted that some of these variations may have grammar issues.

Although not strictly ambiguous with conditional expressions, fn ? () would require the use of YACG (yet another cover grammar).

Also, what about computed property names? For example: obj ? [Symbol.iterator]. I'm not sure that even YACG will help here.

(Thanks for compiling the list of previous threads BTW).

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/6aadf075/attachment-0001.html

joe wrote:

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

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

joe wrote:

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

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

/be

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich <brendan at mozilla.org> 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

Matthew Robb

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich 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

Matthew Robb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/e4ce339b/attachment.html

Yeah, and it would line up with cover grammar needed for refutable-by-default patterns.

/be

Matthew Robb wrote:

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> 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

Matthew Robb

So I take it most would prefer this as a prefix operator. What would be the next steps involved to iterate on this idea?

On Mon, Apr 6, 2015 at 3:35 PM, Brendan Eich wrote:

Yeah, and it would line up with cover grammar needed for refutable-by-default patterns.

/be

Matthew Robb wrote:
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> 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

Matthew Robb
es-discuss mailing list es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-- Christoph Pojer http://cpojer.net

Wouldn't .? as an infix operator be unambiguous, compared to ?.? There's no place other than decimal literals where this would be legal today, and decimal literals already require either parenthesis or an extra dot to perform a property access in any event. With that lexeme, x.?1:y would be unambiguously an error. 1.?x:y is unambiguously a conditional, while 1..?x:y is unambiguously a null-propagating property access on the numeric literal 1..

Ron

-----Original Message----- From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich Sent: Monday, April 6, 2015 3:35 PM To: Matthew Robb Cc: es-discuss Subject: Re: Existential Operator / Null Propagation Operator

Yeah, and it would line up with cover grammar needed for refutable-by-default patterns.

/be

Matthew Robb wrote:

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> 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

Matthew Robb

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

Implement it; user-test it; auto-check the grammar for ambiguity and other problems.

/be

Christoph Pojer wrote:

So I take it most would prefer this as a prefix operator. What would be the next steps involved to iterate on this idea?

On Mon, Apr 6, 2015 at 3:35 PM, Brendan Eich wrote:
Yeah, and it would line up with cover grammar needed for refutable-by-default patterns.

/be

Matthew Robb wrote:
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich<brendan at mozilla.org <mailto:brendan at mozilla.org>> 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

Matthew Robb
es-discuss mailing list es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer <christoph.pojer at gmail.com>

wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39:Microsoft/TypeScript#16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1

Hold on, I guess it's a typo, since as discussed in the internal conversation, and based on the implementation, your current prototype transform implements option (2). I.e. it's not yet compositional. CoffeeScript also has option (2), and is not compositional, since:

a?.b.c and (a?.b).c have different semantics in case if a is null.

but we'd be happy to build a reference implementation for option #2.

Yeah, (2) will make it compositional.

I recall that another issue was that of transitivity. Right now, (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be equivalent expressions. I think we need some input from the people on this list about whether this is okay or why we value transitivity for this operator.

Yeah, potentially we could agree it's being non-compositional. Otherwise, it will be full-chain "verbose" version. I.e. to get a null-safe dproperty, you should write ? after each property access:

var v = a?.b?.c?.d

In other words, it's the same as:

var v = (((a?.b)?.c)?.d)

and in this case it becomes compositional (the semantics doesn't change whether you apply grouping operator or not).

But again, as was mentioned in [1], probably it's "too verbose", and hence may not hit standardization. I'd say it's fine -- it works in most of the case, and usually should not be that verbose. OTOH, we still may have a non-compositional (short-circuiting) version.

FWIW, in Hack programming language I also implemented the "verbose" version, hence it's compositional. The details of the implementation can be found in [2] (we've just recently added it to Hack).

On the topic whether it should be prefix or postfix: I'd personally prefer postfix, since it will be intuitive from other languages. However, if we won't be able to solve all grammar challenges, prefix version could be fined as well.

[1] esdiscuss.org/topic/the-existential-operator#content-19[2]facebook/hhvm/commit/35819cdcf2c80edc22fb3e2e4a6a27f352fb9305

Dmitry

On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer <christoph.pojer at gmail.com> wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39: https://github.com/Microsoft/TypeScript/issues/16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1

a?.b.c and (a?.b).c have different semantics in case if a is null.

but we'd be happy to build a reference implementation for option #2.

Yeah, (2) will make it compositional.

I recall that another issue was that of transitivity. Right now, (a.b).c and a.b.c are equivalent. (a?.b).c and a?.b.c would not be equivalent expressions. I think we need some input from the people on this list about whether this is okay or why we value transitivity for this operator.

Yeah, potentially we could agree it's being non-compositional. Otherwise, it will be full-chain "verbose" version. I.e. to get a null-safe d property, you should write ? after each property access:

var v = a?.b?.c?.d

In other words, it's the same as:

var v = (((a?.b)?.c)?.d)

and in this case it becomes compositional (the semantics doesn't change whether you apply grouping operator or not).

FWIW, in Hack programming language I also implemented the "verbose" version, hence it's compositional. The details of the implementation can be found in [2] (we've just recently added it to Hack).

[1] https://esdiscuss.org/topic/the-existential-operator#content-19 [2] https://github.com/facebook/hhvm/commit/35819cdcf2c80edc22fb3e2e4a6a27f352fb9305

Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/0f892e6b/attachment-0001.html

On Mon, Apr 6, 2015 at 6:35 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com

wrote:

On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer < christoph.pojer at gmail.com> wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39:Microsoft/TypeScript#16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1

Hold on, I guess it's a typo, since as discussed in the internal conversation, and based on the implementation, your current prototype transform implements option (2). I.e. it's not yet compositional. CoffeeScript also has option (2), and is not compositional, since:

a?.b.c and (a?.b).c have different semantics in case if a is null.

but we'd be happy to build a reference implementation for option #2.

Yeah, (2) will make it compositional.

Err, option (1) I meant of course.

Dmitry

On Mon, Apr 6, 2015 at 6:35 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com

wrote:

On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer < christoph.pojer at gmail.com> wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39: https://github.com/Microsoft/TypeScript/issues/16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1

Hold on, I guess it's a typo, since as discussed in the internal conversation, and based on the implementation, your current prototype transform implements option (2). I.e. it's not yet compositional. CoffeeScript also has option (2), and is not compositional, since:

a?.b.c and (a?.b).c have different semantics in case if a is null.

but we'd be happy to build a reference implementation for option #2.

Yeah, (2) will make it compositional.

Err, option (1) I meant of course.

Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/69f64a73/attachment.html

We should perhaps review this old thread:

https://esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

On Mon, Apr 6, 2015 at 10:05 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:

On Mon, Apr 6, 2015 at 6:35 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:

On Mon, Apr 6, 2015 at 11:33 AM, Christoph Pojer < christoph.pojer at gmail.com> wrote:

Tim Yung and I have hacked on a reference implementation for the "Existential Operator" using esprima-fb and jstransform: "a?.b"

Example:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

This must also make sure that a only gets evaluated a single time.

Based on previous discussions on es-discuss and TC39, it seems that this was tabled for ES6. I think now is a good time to bring it up for ES7. There is precendence for this feature in other languages - it was recently added to C# and Hack and has always been in CoffeeScript. TypeScript is waiting for TC39: https://github.com/Microsoft/TypeScript/issues/16

In the past, this topic has invited a lot of bikeshedding, but I'd like us to look past this. Several communities within and outside the JS community have identified the need for this operator. My understanding is that a decision needs to be made about whether the operator should short-circuit additional invocations in the call chain if the operand is null (aka. null propagation).

For example, if a is null, should a?.b.c:

evaluate to (void 0).c and throw a TypeError?

short-circuit at a and return void 0?

It appears that C# chose option #2 whereas Hack and CoffeeScript chose option #1. Our current implementation chose option #1

Hold on, I guess it's a typo, since as discussed in the internal conversation, and based on the implementation, your current prototype transform implements option (2). I.e. it's not yet compositional. CoffeeScript also has option (2), and is not compositional, since:

a?.b.c and (a?.b).c have different semantics in case if a is null.

but we'd be happy to build a reference implementation for option #2.

Yeah, (2) will make it compositional.

Err, option (1) I meant of course.

Dmitry

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/4afe37ce/attachment.html

That (putting the ? second) works for . ( and [, true. It's backwards compared to other languages, though. Oh well.

The deeper issue is semantic, assuming a viable syntax. See ksmith's latest message.

That (putting the ? second) works for . ( and [, true. It's backwards compared to other languages, though. Oh well.

The deeper issue is semantic, assuming a viable syntax. See ksmith's latest message.

/be

Ron Buckton wrote:

Wouldn't .? as an infix operator be unambiguous, compared to ?.? There's no place other than decimal literals where this would be legaltoday, and decimal literals already require either parenthesis or an extra dot to perform a property access in any event. With that lexeme, x.?1:y would be unambiguously an error. 1.?x:y is unambiguously a conditional, while 1..?x:y is unambiguously a null-propagating property access on the numeric literal 1..

Ron

Kevin Smith wrote:

We should perhaps review this old thread:

esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

Yeah, that's the Null Pattern I mentioned few posts before. I remember I suggested this to be part of the language itself, as a first-class member, but it seems it wasn't legible; OTOH, it seemed to be good enough to use while still in the level of references, but when coming back to values, it was suggested to be changed to undefined.

It is still interesting question if it could be part of the language itself, but even if not and only applicable as a reference, it can be a good solution (it that case a?.b.c would yield undefined, not an error in case a is null).

Kevin Smith wrote:

We should perhaps review this old thread:

https://esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

Herby

On 6 April 2015 at 19:33, Christoph Pojer <christoph.pojer at gmail.com> wrote:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

Would it not be more generally useful if it returned "a" rather than "void 0" in the appropriate case, that is:

a?.b => (a == null ? a : a.b)

This way the notion of nullness/undefinedness the user is working with would be preserved.

On 6 April 2015 at 19:33, Christoph Pojer <christoph.pojer at gmail.com> wrote:

a?.b => (a == null ? void 0 : a.b) a?.b.c => (a == null ? void 0 : a.b.c)

Would it not be more generally useful if it returned "a" rather than "void 0" in the appropriate case, that is:

a?.b => (a == null ? a : a.b)

This way the notion of nullness/undefinedness the user is working with would be preserved. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/cb6ab056/attachment.html

On 6 April 2015 at 20:01, Jordan Harband <ljharb at gmail.com> wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.cin that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

On 6 April 2015 at 20:01, Jordan Harband wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.c in that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

Also you are not forced to use separate variables in option 2, you can just use parentheses: (a?.b).c - hence the whole discussion of lack of transitivity (more correctly, associativity) for option 2. Or did I misunderstand what you're trying to achieve? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/104a5fc1/attachment.html

On 7 April 2015 at 18:03, Nick Krempel <ndkrempel at google.com> wrote:

On 6 April 2015 at 20:01, Jordan Harband <ljharb at gmail.com> wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.cin that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

Also you are not forced to use separate variables in option 2, you can just use parentheses: (a?.b).c - hence the whole discussion of lack of transitivity (more correctly, associativity) for option 2. Or did I misunderstand what you're trying to achieve?

...but thinking about it further, wouldn't you always want the short circuit semantics? i.e. an option 1 a?.b.c is almost certainly a bug?

On 7 April 2015 at 18:03, Nick Krempel wrote:

On 6 April 2015 at 20:01, Jordan Harband wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.c in that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

Also you are not forced to use separate variables in option 2, you can just use parentheses: (a?.b).c - hence the whole discussion of lack of transitivity (more correctly, associativity) for option 2. Or did I misunderstand what you're trying to achieve?

...but thinking about it further, wouldn't you always want the short circuit semantics? i.e. an option 1 a?.b.c is almost certainly a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/45d400d3/attachment-0001.html

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing.

On Tue, Apr 7, 2015 at 10:07 AM, Nick Krempel wrote:

On 7 April 2015 at 18:03, Nick Krempel wrote:

On 6 April 2015 at 20:01, Jordan Harband wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.c in that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

Also you are not forced to use separate variables in option 2, you can just use parentheses: (a?.b).c - hence the whole discussion of lack of transitivity (more correctly, associativity) for option 2. Or did I misunderstand what you're trying to achieve?

...but thinking about it further, wouldn't you always want the short circuit semantics? i.e. an option 1 a?.b.c is almost certainly a bug?

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

-- Christoph Pojer http://cpojer.net

Christoph Pojer wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing.

What do you mean? JS does not have static typing. Even if it got it via SoundScript, the new mode would be an opt-in. The default and vast majority of JS, which might like to use ?. (or whatever the syntax should be), could not rely on types.

Kevin's suggestion is that we solve the non-compositional CoffeeScript-like translation problem by converting null-ish (null or undefined) left operand of ?. (I'll use that syntax for now as it is familiar) to the Nil (h/t bbenvie) value proxy, which soaks up further property accesses by returning itself, and soaks up calls too.

As a sketch of semantics, this seems promising (no appeal to static typing) but I'm low on caffeine at the moment. What am I missing?

Christoph Pojer wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing.

As a sketch of semantics, this seems promising (no appeal to static typing) but I'm low on caffeine at the moment. What am I missing?

/be

Kevin Smith wrote:

We should perhaps review this old thread:

esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

Going a bit deeper this way, this thing (changing ref to Nil which always returns Nil upon call, construct and get, and getting back undefined when value is needed) have nicely separated concerns:

Let's say '?foo', as an unary oper ator, when foo is a reference, returns Nil when foo is reference to null or undefined, otherwise leaves it unchanged. Then:

?a.b.c just works, ?d() just works, new ?ei just works, etc,. since ref is changed to Nil if the thing is null/undefined, it propagates through calls and gets, then changes itself to undefined value. The priority of ? must be pretty high, though, to only apply to nearest token.

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

Kevin Smith wrote:

We should perhaps review this old thread:

https://esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

Going a bit deeper this way, this thing (changing ref to Nil which always returns Nil upon call, construct and get, and getting back undefined when value is needed) have nicely separated concerns:

Let's say '?foo', as an unary oper ator, when foo is a reference, returns Nil when foo is reference to null or undefined, otherwise leaves it unchanged. Then:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

Herby

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special

operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/e317aed8/attachment.html

Christoph Pojer wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced

Oh, that is completely different semantics. IMNSHO, it goes against DWIM.

Christoph Pojer wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced

Oh, that is completely different semantics. IMNSHO, it goes against DWIM.

through static typing.

On Tue, Apr 7, 2015 at 10:07 AM, Nick Krempel wrote:

On 7 April 2015 at 18:03, Nick Krempel wrote:

On 6 April 2015 at 20:01, Jordan Harband wrote:

If I want the short circuit in option 1, I'd do a?.b?.c to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables.

Worth noting that an option 1 a?.b?.c differs from an option 2 a?.b.c in that the latter is effectively asserting that if a != null then its b property is also != null, whereas the former is more lenient in what it accepts.

Also you are not forced to use separate variables in option 2, you can just use parentheses: (a?.b).c - hence the whole discussion of lack of transitivity (more correctly, associativity) for option 2. Or did I misunderstand what you're trying to achieve?

...but thinking about it further, wouldn't you always want the short circuit semantics? i.e. an option 1 a?.b.c is almost certainly a bug?

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

Kevin Smith wrote:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

While you do operations like call, construct, get on the reference (obtaining another reference), it shortcuts to return Nil. Whenever you are not in position to shortcut ref-to-ref (end of expression, for example), and you actually needs a value, it just converts to undefined.

?a.b()['foo'] => "smalltalk-like" (((('a' asRefIn: env) nilRefIfValueNullOrUndefined "ref, may be nil" at: 'b') "returns ref, may be Nil" callWithArguments: #()) "returns ref, may be Nil" at: 'foo') "returns ref, may be Nil") value "now, value is needed, ref needs to dereference"

Hopefully this sheds some light. If not, then I don't know how to explain it someone with better pedagogy skill must weight in.

Kevin Smith wrote:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

Hopefully this sheds some light. If not, then I don't know how to explain it someone with better pedagogy skill must weight in.

Am I crazy to think that "Nil" could allow the Existential Operator to be used in assignments as well?

var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}}

Too powerful / abusive?

Day dreaming, use U+02D9 (DOT ABOVE) as the operator.

a˙b˙c.d

Am I crazy to think that "Nil" could allow the Existential Operator to be used in assignments as well?

var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}}

Too powerful / abusive?

Day dreaming, use U+02D9 (DOT ABOVE) as the operator.

a˙b˙c.d

On Tue, Apr 7, 2015 at 1:09 PM, Herby Vojčík wrote:

Kevin Smith wrote:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

While you do operations like call, construct, get on the reference (obtaining another reference), it shortcuts to return Nil. Whenever you are not in position to shortcut ref-to-ref (end of expression, for example), and you actually needs a value, it just converts to undefined.

?a.b()['foo'] => "smalltalk-like" (((('a' asRefIn: env) nilRefIfValueNullOrUndefined "ref, may be nil" at: 'b') "returns ref, may be Nil" callWithArguments: #()) "returns ref, may be Nil" at: 'foo') "returns ref, may be Nil") value "now, value is needed, ref needs to dereference"

Hopefully this sheds some light. If not, then I don't know how to explain it someone with better pedagogy skill must weight in.

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/cb05ecfe/attachment.html

Nathan White wrote:

Am I crazy to think that "Nil" could allow the Existential Operator to be used in assignments as well?

var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}}

Too powerful / abusive?

Too error-prone. E4X (ECMA-357) and languages such as Borland's mid-nineties "Lucy" (Loose C) allow you to cons up deep structures just be expressing member references. One typo and you're lost.

Day dreaming, use U+02D9 (DOT ABOVE) as the operator.

a˙b˙c.d

Object literal notation is explicit and pretty concise. What's the hot use-case driving your desire here?

Nathan White wrote:

Am I crazy to think that "Nil" could allow the Existential Operator to be used in assignments as well?

var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}}

Too powerful / abusive?

Too error-prone. E4X (ECMA-357) and languages such as Borland's mid-nineties "Lucy" (Loose C) allow you to cons up deep structures just be expressing member references. One typo and you're lost.

Day dreaming, use U+02D9 (DOT ABOVE) as the operator.

a˙b˙c.d

Object literal notation is explicit and pretty concise. What's the hot use-case driving your desire here?

/be

On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich <brendan at mozilla.org, 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?

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? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/03fc7a89/attachment.html

Caitlin Potter wrote:

6, 2015 at 5:42 PM, Brendan Eich<brendan at mozilla.org, 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?

We can try being this precise, as you say -- but we cannot then handle x?(y) as CoffeeScript does. Instead of being neither fish nor fowl, better to be fowl with leading ?, or use a distinct and regular syntax that handles all the cases we want. My two cents,

Caitlin Potter wrote:

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?

/be

Brendan Eich wrote:

Caitlin Potter wrote:

6, 2015 at 5:42 PM, Brendan Eich<brendan at mozilla.org, 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?

We can try being this precise, as you say -- but we cannot then handle x?(y) as CoffeeScript does. Instead of being neither fish nor fowl, better to be fowl with leading ?, or use a distinct and regular syntax that handles all the cases we want. My two cents,

Worse, we can't even do ?[ as you propose with LR(1) or any similar approach. Here's a bison toy grammar:

%token ID

start: E ;

E: A | E ',' A ;

A: C | M '=' A ;

C: M : M '?' A ':' A ;

M: M '[' E ']' | M '?' '[' E ']' | P ;

P: ID | '(' E ')' | '[' E ']' ;

(P for Primary, M for Member, C for Conditional, A for Assignment.)

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

Brendan Eich wrote:

Caitlin Potter wrote:

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?

We can try being this precise, as you say -- but we cannot then handle x?(y) as CoffeeScript does. Instead of being neither fish nor fowl, better to be fowl with leading ?, or use a distinct and regular syntax that handles all the cases we want. My two cents,

Worse, we can't even do ?[ as you propose with LR(1) or any similar approach. Here's a bison toy grammar:

%token ID

start: E ;

E: A | E ',' A ;

A: C | M '=' A ;

C: M : M '?' A ':' A ;

M: M '[' E ']' | M '?' '[' E ']' | P ;

P: ID | '(' E ')' | '[' E ']' ;

(P for Primary, M for Member, C for Conditional, A for Assignment.)

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

Brendan Eich wrote:

Brendan Eich wrote:

Caitlin Potter wrote:

6, 2015 at 5:42 PM, Brendan Eich<brendan at mozilla.org, 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?

We can try being this precise, as you say -- but we cannot then handle x?(y) as CoffeeScript does. Instead of being neither fish nor fowl, better to be fowl with leading ?, or use a distinct and regular syntax that handles all the cases we want. My two cents,

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

There is also ambiguity due to ASI vs. a ConditionalExpression:

obj ? [ expr ] 
:label

Ron

Brendan Eich wrote:

Brendan Eich wrote:

Caitlin Potter wrote:

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?

We can try being this precise, as you say -- but we cannot then handle x?(y) as CoffeeScript does. Instead of being neither fish nor fowl, better to be fowl with leading ?, or use a distinct and regular syntax that handles all the cases we want. My two cents,

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

There is also ambiguity due to ASI vs. a ConditionalExpression:

obj ? [ expr ] 
:label

Ron

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar.

Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org> wrote:

joe wrote:

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

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

/be

No, it looks like I didn't.

Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich wrote:

joe wrote:

By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token:

COND_DOT : ?.

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

/be

No, it looks like I didn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/3c6bfadd/attachment-0001.html

Ron Buckton wrote:

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

There is also ambiguity due to ASI vs. a ConditionalExpression:
obj ? [ expr ]
:label
Ron

Colon goes after label :-P. But the problem is bounded lookahead, ideally k=1. We are not specifying backtracking...

Ron Buckton wrote:

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

There is also ambiguity due to ASI vs. a ConditionalExpression:
obj ? [ expr ]
:label
Ron

Colon goes after label :-P. But the problem is bounded lookahead, ideally k=1. We are not specifying backtracking...

/be

joe wrote:

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead.
Although I suppose at that point you might as well call it a cover grammar.

We must avoid being too clever -- it complicates implementations and inevitably incurs future-hostility to extensions we may want, if not outright bugginess.

All of this suggests prefix ? is the better course. Anyone have counterexamples?

joe wrote:

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead.
Although I suppose at that point you might as well call it a cover grammar.

We must avoid being too clever -- it complicates implementations and inevitably incurs future-hostility to extensions we may want, if not outright bugginess.

All of this suggests prefix ? is the better course. Anyone have counterexamples?

/be

Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
joe wrote:

    By the way, I don't remember having grammar issues (I use a
    LALR compiler-compiler).  Looking at my code, it looked like I
    handled it in the tokenizer stage; I added a COND_DOT token:

    COND_DOT : \?\.


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

/be
No, it looks like I didn't.

Oops, was think in batch for a minute there.

Sent from my Windows Phone

Oops, was think in batch for a minute there.

Sent from my Windows Phone

From: Brendan Eich<mailto:brendan at mozilla.org> Sent: ‎4/‎7/‎2015 6:23 PM To: Ron Buckton<mailto:Ron.Buckton at microsoft.com> Cc: Caitlin Potter<mailto:caitpotter88 at gmail.com>; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org> Subject: Re: Existential Operator / Null Propagation Operator

Ron Buckton wrote:

The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity.

/be

There is also ambiguity due to ASI vs. a ConditionalExpression:
obj ? [ expr ]
:label
Ron

Colon goes after label :-P. But the problem is bounded lookahead, ideally k=1. We are not specifying backtracking...

/be -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150408/fe300bbd/attachment.html

Okay. I've updated my transpiler to demonstrate how (and why) this could work at the VM level (I do think VM devs will have to add new opcodes for this), and I've appended an example transformation to this email.

Why is this so complicationed? The answer is that when you start nesting ?. operators, it's pretty easy to cause some operators to be called twice.

E.g, if you transformed the following to the NULL syntax:

a?.d().f?.b

You would get: (a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b : undefined) : undefined)));

Notice how a.d() gets called multiple times.

The solution is probably new VM opcodes. Since my transpiler is obviously not a VM, it transforms ?. operators into auto-generated functions. Anyway, here's the example I transpiler:

a?.b.c.e?.f.g?.h.t.c?.d()?.e;

Which turned into this:

function q0eILlfx7_3(obj) { var _t=obj;

if (_t==undefined)
  return undefined;
_t = _t.b.c.e;

if (_t==undefined)
  return undefined;
_t = _t.f.g;

if (_t==undefined)
  return undefined;
_t = _t.h.t.c;

if (_t==undefined)
  return undefined;
_t = _t.d();

return _t;

}

q0eILlfx7_3(a);

Why is this so complicationed? The answer is that when you start nesting ?. operators, it's pretty easy to cause some operators to be called twice.

E.g, if you transformed the following to the NULL syntax:

a?.d().f?.b

You would get: (a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b : undefined) : undefined)));

Notice how a.d() gets called multiple times.

The solution is probably new VM opcodes. Since my transpiler is obviously not a VM, it transforms ?. operators into auto-generated functions. Anyway, here's the example I transpiler:

a?.b.c.e?.f.g?.h.t.c?.d()?.e;

Which turned into this:

function q0eILlfx7_3(obj) { var _t=obj;

if (_t==undefined)
  return undefined;
_t = _t.b.c.e;

if (_t==undefined)
  return undefined;
_t = _t.f.g;

if (_t==undefined)
  return undefined;
_t = _t.h.t.c;

if (_t==undefined)
  return undefined;
_t = _t.d();

return _t;

}

q0eILlfx7_3(a);

On Tue, Apr 7, 2015 at 6:24 PM, Brendan Eich wrote:

joe wrote:

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar.

We must avoid being too clever -- it complicates implementations and inevitably incurs future-hostility to extensions we may want, if not outright bugginess.

All of this suggests prefix ? is the better course. Anyone have counterexamples?

/be
Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
joe wrote:

    By the way, I don't remember having grammar issues (I use a
    LALR compiler-compiler).  Looking at my code, it looked like I
    handled it in the tokenizer stage; I added a COND_DOT token:

    COND_DOT : \?\.


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

/be
No, it looks like I didn't.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/7cf3867e/attachment-0001.html

No, you’d just memoise it to a variable:

a?.d().f?.b

to:

var _temp, _temp2;

(a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined ? _temp2.b : undefined) : undefined)));

You’re going to need to memoise all member expressions anyway as they might be accessing a getter and you don’t want to call it twice.

No, you’d just memoise it to a variable:

a?.d().f?.b

to:

var _temp, _temp2;

(a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined ? _temp2.b : undefined) : undefined)));

You’re going to need to memoise all member expressions anyway as they might be accessing a getter and you don’t want to call it twice.

On Tue, Apr 7, 2015 at 7:32 PM, joe wrote:

Okay. I've updated my transpiler to demonstrate how (and why) this could work at the VM level (I do think VM devs will have to add new opcodes for this), and I've appended an example transformation to this email. Why is this so complicationed? The answer is that when you start nesting ?. operators, it's pretty easy to cause some operators to be called twice. E.g, if you transformed the following to the NULL syntax: a?.d().f?.b You would get: (a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b : undefined) : undefined))); Notice how a.d() gets called multiple times. The solution is probably new VM opcodes. Since my transpiler is obviously not a VM, it transforms ?. operators into auto-generated functions. Anyway, here's the example I transpiler: a?.b.c.e?.f.g?.h.t.c?.d()?.e; Which turned into this: function q0eILlfx7_3(obj) { var _t=obj; if (_t==undefined) return undefined; _t = _t.b.c.e; if (_t==undefined) return undefined; _t = _t.f.g; if (_t==undefined) return undefined; _t = _t.h.t.c; if (_t==undefined) return undefined; _t = _t.d(); return _t; } q0eILlfx7_3(a); On Tue, Apr 7, 2015 at 6:24 PM, Brendan Eich wrote:
joe wrote:

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar.

We must avoid being too clever -- it complicates implementations and inevitably incurs future-hostility to extensions we may want, if not outright bugginess.

All of this suggests prefix ? is the better course. Anyone have counterexamples?

/be
Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
joe wrote:

    By the way, I don't remember having grammar issues (I use a
    LALR compiler-compiler).  Looking at my code, it looked like I
    handled it in the tokenizer stage; I added a COND_DOT token:

    COND_DOT : \?\.


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

/be
No, it looks like I didn't.
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/4df35294/attachment.html

That looks workable. Does anyone have any more comments on '.?' versus '?.' ?

Joe

That looks workable. Does anyone have any more comments on '.?' versus '?.' ?

Joe

On Tue, Apr 7, 2015 at 7:34 PM, Sebastian McKenzie wrote:

No, you’d just memoise it to a variable:

a?.d().f?.b

to:

var _temp, _temp2; (a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined ? _temp2.b : undefined) : undefined)));

You’re going to need to memoise all member expressions anyway as they might be accessing a getter and you don’t want to call it twice.

On Tue, Apr 7, 2015 at 7:32 PM, joe wrote:
Okay. I've updated my transpiler to demonstrate how (and why) this could work at the VM level (I do think VM devs will have to add new opcodes for this), and I've appended an example transformation to this email.

Why is this so complicationed? The answer is that when you start nesting ?. operators, it's pretty easy to cause some operators to be called twice.

E.g, if you transformed the following to the NULL syntax:

a?.d().f?.b

You would get: (a != undefined ? (a.d() != undefined ? (a.d().f != undefined ? a.d().f.b : undefined) : undefined)));

Notice how a.d() gets called multiple times.

The solution is probably new VM opcodes. Since my transpiler is obviously not a VM, it transforms ?. operators into auto-generated functions. Anyway, here's the example I transpiler:
 a?.b.c.e?.f.g?.h.t.c?.d()?.e;
Which turned into this:
function q0eILlfx7_3(obj) {
var _t=obj;

if (_t==undefined)
  return undefined;
_t = _t.b.c.e;

if (_t==undefined)
  return undefined;
_t = _t.f.g;

if (_t==undefined)
  return undefined;
_t = _t.h.t.c;

if (_t==undefined)
  return undefined;
_t = _t.d();

return _t;
}

q0eILlfx7_3(a);

On Tue, Apr 7, 2015 at 6:24 PM, Brendan Eich wrote:
joe wrote:

That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar.

We must avoid being too clever -- it complicates implementations and inevitably incurs future-hostility to extensions we may want, if not outright bugginess.

All of this suggests prefix ? is the better course. Anyone have counterexamples?

/be
Joe

On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
joe wrote:

    By the way, I don't remember having grammar issues (I use a
    LALR compiler-compiler).  Looking at my code, it looked like I
    handled it in the tokenizer stage; I added a COND_DOT token:

    COND_DOT : \?\.


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

/be
No, it looks like I didn't.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150407/038a22f4/attachment.html

On 7 April 2015 at 18:33, Christoph Pojer <christoph.pojer at gmail.com> wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing.

Under option 1, that's not what it does. Since it's equivalent to(a?.b).c, if a is null/undefined, it will always raise an error, so it's more or less the same as just doing a.b.c.

On 7 April 2015 at 18:33, Christoph Pojer <christoph.pojer at gmail.com> wrote:

it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing.

Under option 1, that's not what it does. Since it's equivalent to (a?.b).c, if a is null/undefined, it will always raise an error, so it's more or less the same as just doing a.b.c. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150408/d0465722/attachment-0001.html

The prefix ? for an absorbing Nil value sounds good.

The semantics of delete may need clarifying; what should the following construct do?

delete ?a.b.c

Most intuitive would be to not raise an error and return true if either theb or c properties are missing, whether or not in strict mode. Does that hold up?

Nick

The prefix ? for an absorbing Nil value sounds good.

The semantics of delete may need clarifying; what should the following construct do?

delete ?a.b.c

Most intuitive would be to not raise an error and return true if either the b or c properties are missing, whether or not in strict mode. Does that hold up?

Nick

On 7 April 2015 at 19:54, Herby Vojčík wrote:

Kevin Smith wrote:

We should perhaps review this old thread:

https://esdiscuss.org/topic/fail-fast-object- destructuring-don-t-add-more-slop-to-sloppy-mode

for another possible way to avoid non-compositionality. (Look for the suggestion about "Nil". It's basically an exotic falsey object which returns itself for any property lookups or calls.)

Going a bit deeper this way, this thing (changing ref to Nil which always returns Nil upon call, construct and get, and getting back undefined when value is needed) have nicely separated concerns:

Let's say '?foo', as an unary oper ator, when foo is a reference, returns Nil when foo is reference to null or undefined, otherwise leaves it unchanged. Then:

?a.b.c just works, ?d() just works, new ?ei just works, etc,. since ref is changed to Nil if the thing is null/undefined, it propagates through calls and gets, then changes itself to undefined value. The priority of ? must be pretty high, though, to only apply to nearest token.

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

Herby

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150408/0a3dee27/attachment.html

Le 7 avr. 2015 à 21:09, Herby Vojčík <herby at mailbox.sk> a écrit :

Kevin Smith wrote:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

While you do operations like call, construct, get on the reference (obtaining another reference), it shortcuts to return Nil. Whenever you are not in position to shortcut ref-to-ref (end of expression, for example), and you actually needs a value, it just converts to undefined.

?a.b()['foo'] => "smalltalk-like" (((('a' asRefIn: env) nilRefIfValueNullOrUndefined "ref, may be nil" at: 'b') "returns ref, may be Nil" callWithArguments: #()) "returns ref, may be Nil" at: 'foo') "returns ref, may be Nil") value "now, value is needed, ref needs to dereference"

Hopefully this sheds some light. If not, then I don't know how to explain it someone with better pedagogy skill must weight in.

Here is another, more thorough explanation (and how it could be implemented in the spec):

We introduce a special unique additional Reference [6.2.3 ReferenceType], that we call “the Nil Reference”. Unlike other resolvable References, it does not have a concrete binding at its backend, but it is more like a /dev/null or /dev/zero device. The Nil Reference has the following properties:

when read [6.2.3.1 GetValue], it produces undefined;
when written [6.2.3.2 PutValue] or deleted [12.5.4 deleteOperator], it acts like a blackhole;
as a more exotic behaviour, when it appears when evaluating the leftmost term of a property accessor [12.3.2 PropertyAccessors] or a function call [12.3.4 FunctionCalls], it is not dereferenced to undefined so that a TypeError would be thrown. Rather, the subexpression evaluates to the Nil Reference again. For example, here is how some algorithms of the of the spec could be modified in order to implement the "forwarding" behaviour of the Nil Reference:
MemberExpression : MemberExpression [ Expression ] (section 12.3.2.1)
1. Let baseReference be the result of evaluating MemberExpression.
2. ReturnIfAbrupt(baseReference).
3. If baseReference is the Nil Reference, return the Nil Reference.
4. Let baseValue be RequireObjectCoercible(GetValue(baseReference)).
5. ReturnIfAbrupt(baseValue). 6, Let propertyNameReference be the result of evaluating Expression.
6. Let propertyKey be ToPropertyKey(GetValue(propertyNameReference)).
7. ReturnIfAbrupt(propertyKey).
8. Return a Reference whose base is baseValue and whose referenced name is propertyKey, (and whose “strict” flag, etc.)
  CallExpression : MemberExpression Arguments (section 12.3.4.1)
9. Let ref be the result of evaluating MemberExpression.
10. ReturnIfAbrupt(ref).
11. If ref is the Nil Reference, return the Nil Reference.
12. Let func be GetValue(ref).
13. etc.

Le 7 avr. 2015 à 21:09, Herby Vojčík a écrit :

Kevin Smith wrote:

Plus, it can be used for "normalizing" null/undefined to undefined:

var normalizedFoo = ?foo;

Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[.

I agree, that is nice. But how does Nil get transformed into undefined?

While you do operations like call, construct, get on the reference (obtaining another reference), it shortcuts to return Nil. Whenever you are not in position to shortcut ref-to-ref (end of expression, for example), and you actually needs a value, it just converts to undefined.

?a.b()['foo'] => "smalltalk-like" (((('a' asRefIn: env) nilRefIfValueNullOrUndefined "ref, may be nil" at: 'b') "returns ref, may be Nil" callWithArguments: #()) "returns ref, may be Nil" at: 'foo') "returns ref, may be Nil") value "now, value is needed, ref needs to dereference"

Hopefully this sheds some light. If not, then I don't know how to explain it someone with better pedagogy skill must weight in.

Here is another, more thorough explanation (and how it could be implemented in the spec):

when read [6.2.3.1 GetValue], it produces undefined;
when written [6.2.3.2 PutValue] or deleted [12.5.4 deleteOperator], it acts like a blackhole;
as a more exotic behaviour, when it appears when evaluating the leftmost term of a property accessor [12.3.2 PropertyAccessors] or a function call [12.3.4 FunctionCalls], it is not dereferenced to undefined so that a TypeError would be thrown. Rather, the subexpression evaluates to the Nil Reference again. For example, here is how some algorithms of the of the spec could be modified in order to implement the "forwarding" behaviour of the Nil Reference:

MemberExpression : MemberExpression [ Expression ] (section 12.3.2.1)
1. Let baseReference be the result of evaluating MemberExpression.
2. ReturnIfAbrupt(baseReference).
3. If baseReference is the Nil Reference, return the Nil Reference.
4. Let baseValue be RequireObjectCoercible(GetValue(baseReference)).
5. ReturnIfAbrupt(baseValue). 6, Let propertyNameReference be the result of evaluating Expression.
6. Let propertyKey be ToPropertyKey(GetValue(propertyNameReference)).
7. ReturnIfAbrupt(propertyKey).
8. Return a Reference whose base is baseValue and whose referenced name is propertyKey, (and whose “strict” flag, etc.)
CallExpression : MemberExpression Arguments (section 12.3.4.1)
1. Let ref be the result of evaluating MemberExpression.
2. ReturnIfAbrupt(ref).
3. If ref is the Nil Reference, return the Nil Reference.
4. Let func be GetValue(ref).
5. etc.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150408/481fe91c/attachment.html

I think it's a good idea to attempt to express these ideas using existing syntax and see what that might look like.

So, for a bit of fun, I wrote this:

gist.github.com/zenparsing/9ff3036b6eb15fa436e4

Basically, there's a Maybe function which returns a proxy over a target, and returns Maybes for calls and gets. Then there's a Definitely function that unwraps the Maybe (unwrapping Nothing to undefined of course).

let scriptParent =

Definitely(Maybe(window).document.scripts[0].parentNode);

If you wanted syntactic sugar for this kind of thing, you'd probably want postfix operators to replace the Maybe and Definitely function calls.

Swift does something similar with "?" and "!":

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

This is kind of a generic monad pattern though, so it would be cool if the syntax could be applied to other monad-ish things.

I think it's a good idea to attempt to express these ideas using existing syntax and see what that might look like.

So, for a bit of fun, I wrote this:

https://gist.github.com/zenparsing/9ff3036b6eb15fa436e4

let scriptParent =

Definitely(Maybe(window).document.scripts[0].parentNode);

If you wanted syntactic sugar for this kind of thing, you'd probably want postfix operators to replace the Maybe and Definitely function calls.

Swift does something similar with "?" and "!":

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

This is kind of a generic monad pattern though, so it would be cool if the syntax could be applied to other monad-ish things. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150424/bcdcec43/attachment-0001.html

(I hope this arrives in the right thread, it's meant as a reply foresdiscuss.org/topic/existential-operator-null-propagation-operator )

I very much like the proposal, our JS code is full with cases where certain components can be null, but we need to execute an action with the component when it's not null.

However, the collisions with existing syntax is indeed troublesome. So far, I liked the ?., ?[ and ?( operators the most.

But what should be done with cases like obj?[1]?[2]:[3]. Does it testobj?[1] and returns [2] or [3] depending on the result, or does it test obj and return [1]?[2] or [3] depending on the result.

A similar case with functions: func1?(func2)?(func3):(func4). Does it test func1?(func2), or can it return (func2)?(func3)?

Both cases depend on the binding to the : of the ternary operator. Which might cause too many changes to the spec, and too many exceptions to keep the language compatible.

The .? operator seems to have no alternative for variable keys (obj[key]), which is IMO the most usefull use-case (testing explicitly for null is most likely to happen when you don't know a lot about the object when writing the code, so likely you also don't know the key). As such .? isn't an option for me.

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a key k1, but if k1 exists, you know it will also have a key k2 a level deeper. With the suffix operator, this would be obj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2] (which again has the same problems as first described with the ?[ operator), while it could also beobj[?k1][k2] (which even conflicts with itself, as it could also test ifk1 as a variable is non-null).

As such, all these proposals have at least as many issues as ?.. And ?.already has too many issues to implement it.

So, I'd like to propose another operator: ?? (with ??[ and ??()

In current syntax, the ? is only used for the ternary operator, and requires something else before and after it. Which means that any code that has ?? is currently invalid.

We currently sometimes use the logical && to test nullness of a value, and access its properties. Like:

var result = obj && obj.key;

Which tests if obj exists (assuming obj is an object when defined), and returns obj.key if it does. With the ?? operator, it can be simplified to

var result = obj??key;

Combined with arr??[idx] and func??(arg), I think this will work very fine.

, Sander

(I hope this arrives in the right thread, it's meant as a reply for https://esdiscuss.org/topic/existential-operator-null-propagation-operator )

I very much like the proposal, our JS code is full with cases where certain components can be null, but we need to execute an action with the component when it's not null.

However, the collisions with existing syntax is indeed troublesome. So far, I liked the ?., ?[ and ?( operators the most.

But what should be done with cases like obj?[1]?[2]:[3]. Does it test obj?[1] and returns [2] or [3] depending on the result, or does it test obj and return [1]?[2] or [3] depending on the result.

A similar case with functions: func1?(func2)?(func3):(func4). Does it test func1?(func2), or can it return (func2)?(func3)?

Both cases depend on the binding to the : of the ternary operator. Which might cause too many changes to the spec, and too many exceptions to keep the language compatible.

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a key k1, but if k1 exists, you know it will also have a key k2 a level deeper. With the suffix operator, this would be obj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2] (which again has the same problems as first described with the ?[ operator), while it could also be obj[?k1][k2] (which even conflicts with itself, as it could also test if k1 as a variable is non-null).

As such, all these proposals have at least as many issues as ?.. And ?. already has too many issues to implement it.

So, I'd like to propose another operator: ?? (with ??[ and ??()

In current syntax, the ? is only used for the ternary operator, and requires something else before and after it. Which means that any code that has ?? is currently invalid.

We currently sometimes use the logical && to test nullness of a value, and access its properties. Like:

var result = obj && obj.key;

Which tests if obj exists (assuming obj is an object when defined), and returns obj.key if it does. With the ?? operator, it can be simplified to

var result = obj??key;

Combined with arr??[idx] and func??(arg), I think this will work very fine.

Regards, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150602/9e17a0ce/attachment.html

Sander Deryckere wrote:

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a key k1, but if k1 exists, you know it will also have a key k2a level deeper. With the suffix operator, this would beobj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2]

You circled back to the incompatible syntax, ?[, but the prefix idea would have ?obj[k1][k2]. The ? goes in front at the start of an operand, and is thus unambiguous with respect to the ternary operator.

Sander Deryckere wrote:

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a key k1, but if k1 exists, you know it will also have a key k2 a level deeper. With the suffix operator, this would be obj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2]

/be

2015-06-02 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org>:

Sander Deryckere wrote:

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a keyk1, but if k1 exists, you know it will also have a key k2 a level deeper. With the suffix operator, this would be obj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2]

You circled back to the incompatible syntax, ?[, but the prefix idea would have ?obj[k1][k2]. The ? goes in front at the start of an operand, and is thus unambiguous with respect to the ternary operator.

2015-06-02 17:49 GMT+02:00 Brendan Eich :

Sander Deryckere wrote:

For the prefix operator, it's unclear to me how you would do the following: Say you know obj is non-null, you want to test if it has a key k1, but if k1 exists, you know it will also have a key k2 a level deeper. With the suffix operator, this would be obj[k1]?[k2], but with the prefix operator, it could be obj?[k1][k2]

You circled back to the incompatible syntax, ?[, but the prefix idea would have ?obj[k1][k2]. The ? goes in front at the start of an operand, and is thus unambiguous with respect to the ternary operator.

The question is not about the existence of obj, but if obj has a key k1. AFAICS, ?obj[k1][k2] would test the existence of obj, which I don't need in this example. To test the existence of a key inside obj, a prefix operator should come somewhere before the key. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150602/ce04179d/attachment.html

Sander Deryckere wrote:

2015-06-02 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org<mailto:brendan at mozilla.org>>:
Sander Deryckere wrote:

   For the prefix operator, it's unclear to me how you would do
   the following: Say you know `obj` is non-null, you want to
   test if it has a key `k1`, but if `k1` exists, you know it
   will also have a key `k2` a level deeper. With the suffix
   operator, this would be `obj[k1]?[k2]`, but with the prefix
   operator, it could be `obj?[k1][k2]`


You circled back to the incompatible syntax, `?[`, but the prefix
idea would have `?obj[k1][k2]`. The `?` goes in front at the start
of an operand, and is thus unambiguous with respect to the ternary
operator.
The question is not about the existence of obj, but if obj has a key k1. AFAICS, ?obj[k1][k2] would test the existence of obj, which I don't need in this example. To test the existence of a key inside obj, a prefix operator should come somewhere before the key.

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

Sander Deryckere wrote:

2015-06-02 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>>:
Sander Deryckere wrote:

    For the prefix operator, it's unclear to me how you would do
    the following: Say you know `obj` is non-null, you want to
    test if it has a key `k1`, but if `k1` exists, you know it
    will also have a key `k2` a level deeper. With the suffix
    operator, this would be `obj[k1]?[k2]`, but with the prefix
    operator, it could be `obj?[k1][k2]`


You circled back to the incompatible syntax, `?[`, but the prefix
idea would have `?obj[k1][k2]`. The `?` goes in front at the start
of an operand, and is thus unambiguous with respect to the ternary
operator.
The question is not about the existence of obj, but if obj has a key k1. AFAICS, ?obj[k1][k2] would test the existence of obj, which I don't need in this example. To test the existence of a key inside obj, a prefix operator should come somewhere before the key.

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

/be

On 2 June 2015 at 18:57, Brendan Eich <brendan at mozilla.org> wrote:

Sander Deryckere wrote:
2015-06-02 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org <mailto: brendan at mozilla.org>>:
Sander Deryckere wrote:

   For the prefix operator, it's unclear to me how you would do
   the following: Say you know `obj` is non-null, you want to
   test if it has a key `k1`, but if `k1` exists, you know it
   will also have a key `k2` a level deeper. With the suffix
   operator, this would be `obj[k1]?[k2]`, but with the prefix
   operator, it could be `obj?[k1][k2]`


You circled back to the incompatible syntax, `?[`, but the prefix
idea would have `?obj[k1][k2]`. The `?` goes in front at the start
of an operand, and is thus unambiguous with respect to the ternary
operator.
The question is not about the existence of obj, but if obj has a keyk1. AFAICS, ?obj[k1][k2] would test the existence of obj, which I don't need in this example. To test the existence of a key inside obj, a prefix operator should come somewhere before the key.
You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

Hm, what's the meaning of

a[?b[c]]

On 2 June 2015 at 18:57, Brendan Eich wrote:

Sander Deryckere wrote:
2015-06-02 17:49 GMT+02:00 Brendan Eich <brendan at mozilla.org <mailto: brendan at mozilla.org>>:
Sander Deryckere wrote:

    For the prefix operator, it's unclear to me how you would do
    the following: Say you know `obj` is non-null, you want to
    test if it has a key `k1`, but if `k1` exists, you know it
    will also have a key `k2` a level deeper. With the suffix
    operator, this would be `obj[k1]?[k2]`, but with the prefix
    operator, it could be `obj?[k1][k2]`


You circled back to the incompatible syntax, `?[`, but the prefix
idea would have `?obj[k1][k2]`. The `?` goes in front at the start
of an operand, and is thus unambiguous with respect to the ternary
operator.
The question is not about the existence of obj, but if obj has a key k1. AFAICS, ?obj[k1][k2] would test the existence of obj, which I don't need in this example. To test the existence of a key inside obj, a prefix operator should come somewhere before the key.
You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

Hm, what's the meaning of

a[?b[c]]

/Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150602/f1aea1bd/attachment-0001.html

2015-06-02 18:57 GMT+02:00 Brendan Eich <brendan at mozilla.org>:

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

Which is why my proposal was about ??. I believe there's currently no valid way to use a double question mark in JS, so even ??[ should be easy to figure out what it means.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

2015-06-02 18:57 GMT+02:00 Brendan Eich :

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

Which is why my proposal was about ??. I believe there's currently no valid way to use a double question mark in JS, so even ??[ should be easy to figure out what it means.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

I found this syntax to conflict with itself. As Andreas Rossberg says, what does orders[?client.key].price mean? Does it mean "check if the client exists, and if not, return the price of the null order", or does it mean "check if the order for this client exists, and return null if it doesn't"? I don't see a way how both meanings can be made possible with this form of prefix notation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150602/30338d68/attachment.html

On Tue, Jun 2, 2015 at 1:31 PM, Sander Deryckere <sanderd17 at gmail.com> wrote:

2015-06-02 18:57 GMT+02:00 Brendan Eich <brendan at mozilla.org>:

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

Which is why my proposal was about ??. I believe there's currently no valid way to use a double question mark in JS, so even ??[ should be easy to figure out what it means.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

I found this syntax to conflict with itself. As Andreas Rossberg says, what does orders[?client.key].price mean? Does it mean "check if the client exists, and if not, return the price of the null order", or does it mean "check if the order for this client exists, and return null if it doesn't"? I don't see a way how both meanings can be made possible with this form of prefix notation.

Um, if I'm reading Brenden correctly, neither?

"check if the client exists, and if not, return the price of the null order"

===> orders[client.?key].price

"check if the order for this client exists, and return null if it doesn't"

===> orders[client.key].?price

I would suggest a third interpretation for orders[?client.key].price:

===> (orders ? orders[client.key] : null).price

I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Something that might be more obvious but requires an additional character: orders.?[client.key].price.

More precisely, the suggestion is to standardize on .? and allow it to be followed by either a simple name, a square bracket, or a left paren.

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

Sam Ruby

On Tue, Jun 2, 2015 at 1:31 PM, Sander Deryckere wrote:

2015-06-02 18:57 GMT+02:00 Brendan Eich :

You might hope for that, but as we both noted, ?[ is not going to fly. Don't break the (minified) Web.

Which is why my proposal was about ??. I believe there's currently no valid way to use a double question mark in JS, so even ??[ should be easy to figure out what it means.

The prefix idea generalizes:

?obj[key] obj[?key] obj[key1][?key2]

and if you are not using computed property names, rather literal ones:

obj.?prop1 etc.

I found this syntax to conflict with itself. As Andreas Rossberg says, what does orders[?client.key].price mean? Does it mean "check if the client exists, and if not, return the price of the null order", or does it mean "check if the order for this client exists, and return null if it doesn't"? I don't see a way how both meanings can be made possible with this form of prefix notation.

Um, if I'm reading Brenden correctly, neither?

"check if the client exists, and if not, return the price of the null order"

===> orders[client.?key].price

"check if the order for this client exists, and return null if it doesn't"

===> orders[client.key].?price

I would suggest a third interpretation for orders[?client.key].price:

===> (orders ? orders[client.key] : null).price

I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Something that might be more obvious but requires an additional character: orders.?[client.key].price.

More precisely, the suggestion is to standardize on .? and allow it to be followed by either a simple name, a square bracket, or a left paren.

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

Sam Ruby

Sam Ruby wrote:

I think that the problem here isn't that it is ambiguous, it is that it isn't obvious.

Fair point!

Something that might be more obvious but requires an additional character: orders.?[client.key].price.

That's not bad. The whole proposal may founder, though, on "grawlix" objections.

And some still want the ?obj.foo.bar to "soak" null/undefined obj and missing foo or null/undefined value of foo. CoffeeScript fans for sure, but it's in principle and practice at least as valid a use-case as obj.?foo is.

Sam Ruby wrote:

I think that the problem here isn't that it is ambiguous, it is that it isn't obvious.

Fair point!

Something that might be more obvious but requires an additional character: orders.?[client.key].price.

That's not bad. The whole proposal may founder, though, on "grawlix" objections.

/be

@Sam Ruby: I think we should indeed go for an extra character. In the proposals that result in ?[ and similar, it may be possible to define correctly in the spec, but it would indeed be non-obvious for humans to interprete, and potentially make the parser slower.

I proposed ?? as a unique double character, but .? could also work, and perhaps be easier to read (?? is a bit heavy on the eye with two big glyphs). The only confusion that could happen (AFAICS) is when mixing the decimal point with the ternary operator. But the spec already states that a digit followed by a point is always a decimal point (which is why we need to do (255).toString(2)). So the parser only has to look very locally to find the correct interpretation. And it helps humans too.

@Brendan: yes, soaking up all null/undefined values will probably be wanted by some. But personally, I'd prefer to show in my code where exactly null values can be expected, and where stuff should always be defined. Using the null-soaking syntax too much might result in code that's hard to debug (some null is coming from somewhere, but nobody has an idea from where, as it's just propagating through all accessors).

Thanks for all your comments.

, Sander

2015-06-02 20:30 GMT+02:00 Brendan Eich <brendan at mozilla.org>:

Thanks for all your comments.

Regards, Sander

2015-06-02 20:30 GMT+02:00 Brendan Eich :

Sam Ruby wrote:

I think that the problem here isn't that it is ambiguous, it is that it isn't obvious.

Fair point!

Something that might be more obvious but requires

an additional character: orders.?[client.key].price.

That's not bad. The whole proposal may founder, though, on "grawlix" objections.

And some still want the ?obj.foo.bar to "soak" null/undefined obj and missing foo or null/undefined value of foo. CoffeeScript fans for sure, but it's in principle and practice at least as valid a use-case as obj.?foo is.

/be

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150603/fab89570/attachment-0001.html

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 — usejsdoc.org/tags-type.html

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150819/c5f08a27/attachment.html

-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 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150819/d1ae805a/attachment-0001.html

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

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 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 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-- Sincerely,

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.

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150819/32095f85/attachment.html

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

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150819/c6ebed63/attachment.html

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

On 19 August 2015 at 16:21, Tingan Ho <tingan87 at 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.

On 19 August 2015 at 16:21, Tingan Ho 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.

/Andreas

On Wed, Aug 19, 2015 at 10:09 PM, Kevin Smith 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20150820/13e4b7ed/attachment.html

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

This would be amazing operator!!

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/afd7d6a9/attachment.html

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

, Sander

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/cac5de10/attachment.html

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

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/b2965199/attachment.html

Proposal for variable keys:

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

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/231cd7fa/attachment-0001.html

Yes! I have updated my answer using markdown and also posted on the original issue of TypeScript.Microsoft/TypeScript#16

Is there a better place to propose it for ES6/ES7 ?

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

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:

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.

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!

Should fail as it does now (x.1.y == runtime error)

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.

Should work since it understands that is not a number calling a property from Number.prototype

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:

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:

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

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:

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.

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!

Should fail as it does now (x.1.y == runtime error)

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.

Should work since it understands that is not a number calling a property from Number.prototype

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:

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/09f7019d/attachment.html

As a side note, this feature has recently been added to Ruby (issuebugs.ruby-lang.org/issues/11537). 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 <laurentiu.macovei at gmail.com>

a écrit :

As a side note, this feature has recently been added to Ruby (issue https://bugs.ruby-lang.org/issues/11537). 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 <laurentiu.macovei at gmail.com> 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
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:
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.
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!

Should fail as it does now (x.1.y == runtime error)
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.
Should work since it understands that is not a number calling a property from Number.prototype
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:
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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/d9dccf2f/attachment-0001.html

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

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

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?

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

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

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?

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/037c63e4/attachment.html

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

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

Le 29 oct. 2015 à 19:32, Eli Perelman <eli at eliperelman.com> 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.

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

—Claude

Le 29 oct. 2015 à 21:04, Waldemar Horwat <waldemar at google.com> 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.

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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.
I wouldn't have a problem with object?.[prop], since that's only one character more. It's still a lot easier.
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.
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 <claude.pache at gmail.com> 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151029/33b35cc9/attachment.html

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

Le 29 oct. 2015 à 19:32, Eli Perelman <eli at eliperelman.com> 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

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

Le 30 oct. 2015 à 00:07, Waldemar Horwat <waldemar at google.com> 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.

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

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

On Fri, 30 Oct 2015, 12:23 <es-discuss-request at mozilla.org> wrote:

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

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

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

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

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

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei) (Isiah Meadows)
Re: Existential Operator / Null Propagation Operator (Waldemar Horwat)
Re: Existential Operator / Null Propagation Operator (Claude Pache)
Re: Map literal (Alexander Jones)

---------- Forwarded message ---------- From: Isiah Meadows <isiahmeadows at gmail.com>

To: Ron Waldon <jokeyrhyme at gmail.com>, es-discuss at mozilla.org

Cc: Date: Thu, 29 Oct 2015 23:03:28 +0000 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 <jokeyrhyme at 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:

let value;
try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
// use value without even a basic truthy test

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 at mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit https https://mail.mozilla.org/listinfo/es-discuss:// https://mail.mozilla.org/listinfo/es-discussmail.mozilla.org https://mail.mozilla.org/listinfo/es-discuss/ https://mail.mozilla.org/listinfo/es-discusslistinfo https://mail.mozilla.org/listinfo/es-discuss/ https://mail.mozilla.org/listinfo/es-discusses-discuss https://mail.mozilla.org/listinfo/es-discuss or, via email, send a message with subject or body 'help' to es-discuss-request at mozilla.org

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

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

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei) (Isiah Meadows)
Re: Existential Operator / Null Propagation Operator (Waldemar Horwat)
Re: Existential Operator / Null Propagation Operator (Claude Pache)
Re: Map literal (Alexander Jones)

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

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:

let value;
try { value = deep.deep.deep.prop; } catch (err) { /* ... */ }
// use value without even a basic truthy test

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151030/f4031db0/attachment.html

It's visually ambiguous. I'd rather not read 1..toString() and foo..barin the same file. Not with greatly differing meanings.

It's visually ambiguous. I'd rather not read 1..toString() and foo..bar in the same file. Not with greatly differing meanings.

On Thu, Oct 29, 2015, 19:29 Claude Pache <claude.pache at gmail.com> wrote:

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151030/fc6202df/attachment.html

Le 30 oct. 2015 à 11:11, Isiah Meadows <isiahmeadows at gmail.com> a écrit :

It's visually ambiguous. I'd rather not read 1..toString() and foo..bar in the same file. Not with greatly differing meanings.

No, (1.).toString() and (1)..toString() have strictly the same observable effect, so that their formal difference of semantics can be happily ignored.

Le 30 oct. 2015 à 11:11, Isiah Meadows a écrit :

It's visually ambiguous. I'd rather not read 1..toString() and foo..bar in the same file. Not with greatly differing meanings.

No, (1.).toString() and (1)..toString() have strictly the same observable effect, so that their formal difference of semantics can be happily ignored.

—Claude -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151030/40a3da35/attachment.html

Observable effect doesn't mean same process. Granted, the case with a number literal is very obscure, anyways, so I'm not that worried about it.

On Fri, Oct 30, 2015, 06:20 Claude Pache <claude.pache at gmail.com> wrote:

Le 30 oct. 2015 à 11:11, Isiah Meadows a écrit :

It's visually ambiguous. I'd rather not read 1..toString() and foo..bar in the same file. Not with greatly differing meanings.

No, (1.).toString() and (1)..toString() have strictly the same observable effect, so that their formal difference of semantics can be happily ignored.

—Claude

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20151030/b80cd8d6/attachment-0001.html

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

strawman:existential_operator

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160510/9b06ceac/attachment.html

It is a parser problem:

obj.prop?.2:.1

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

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, <mads.k at jubii.dk> 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160519/cebf91f9/attachment.html

Le 19 mai 2016 à 18:46, John Lenz <concavelenz at gmail.com> a écrit :

It is a parser problem:

obj.prop?.2:.1

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

No, you just need a one-character lookahead checking for a digit.

The response of the original question is "mu", because it is possible.

Le 19 mai 2016 à 18:46, John Lenz a écrit :

It is a parser problem:

obj.prop?.2:.1

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

No, you just need a one-character lookahead checking for a digit.

The response of the original question is "mu", because it is possible.

—Claude

On Tue, May 10, 2016 at 10:32 AM, <mads.k at jubii.dk <mailto:mads.k at jubii.dk>> 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 http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator

es-discuss mailing list es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160519/5aa4d18e/attachment.html

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions.

foo((a, {b}) => b)

foo((a, {b}) <= b)

Also, that proposal is not syntactically ambiguous, since numbers are not allowed to start an identifier.

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions.

foo((a, {b}) => b)
foo((a, {b}) <= b)

Also, that proposal is not syntactically ambiguous, since numbers are not allowed to start an identifier.

On Thu, May 19, 2016, 13:10 Claude Pache <claude.pache at gmail.com> wrote:

Le 19 mai 2016 à 18:46, John Lenz a écrit :

It is a parser problem:

obj.prop?.2:.1

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

No, you just need a one-character lookahead checking for a digit.

The response of the original question is "mu", because it is possible.

—Claude

On Tue, May 10, 2016 at 10:32 AM, <mads.k at jubii.dk> 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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160519/151ffbf9/attachment.html

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions.

The syntax is actually specified in terms of cover grammars, not arbitrary lookahead.

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions.

The syntax is actually specified in terms of cover grammars, not arbitrary lookahead. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160519/752463b6/attachment-0001.html

I'm aware it's specified as a cover grammar, which is the easiest way I'm aware of to do it in a traditional declarative grammar. If you're writing a parser, though, you'll probably be using a mixture of lookahead and speculative parsing, or something to that effect, in practice, since it's faster.

On Thu, May 19, 2016, 16:38 Kevin Smith wrote:

I will note that JavaScript does already require n-token lookahead worst

case to disambiguate arrow functions from sequence expressions.

The syntax is actually specified in terms of cover grammars, not arbitrary lookahead.

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160521/9310a761/attachment.html

You need to be very careful hacking around in an ad-hoc parser. It's easy to diverge from the formal (and verified) grammar by accident. Ambiguous grammars with ad-hoc disambiguation rules codified only by your parser's source code are bad business. Voice of experience here.

/be

On Sat, May 21, 2016 at 3:57 PM Isiah Meadows wrote:

I'm aware it's specified as a cover grammar, which is the easiest way I'm aware of to do it in a traditional declarative grammar. If you're writing a parser, though, you'll probably be using a mixture of lookahead and speculative parsing, or something to that effect, in practice, since it's faster.

On Thu, May 19, 2016, 16:38 Kevin Smith wrote:

I will note that JavaScript does already require n-token lookahead worst

case to disambiguate arrow functions from sequence expressions.

The syntax is actually specified in terms of cover grammars, not arbitrary lookahead.

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160524/41af81fd/attachment.html

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

sebmarkbage/ecmascript-undefined-propagation

Rather than introduce new syntax, Sebastian's proposal was to automatically propagate undefined values: if we're about to throw a dot-property-access-on-undefined error, we just return undefined instead.

I could find much discussion about this here, but I did find lots of discussions about approaches involving alternative syntax.

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

https://github.com/sebmarkbage/ecmascript-undefined-propagation

I could find much discussion about this here, but I did find lots of discussions about approaches involving alternative syntax. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160915/da5ba03e/attachment.html

I disagree with silently ignoring property access on null/undefined.

Early errors are nice

Yes, exactly. Errors should fail early and loudly. That's why the strictness of strict mode is useful.

It's no weirder that 123.foo not throwing.

No, it's entirely different, because numbers are object-coercible.

I disagree with silently ignoring property access on null/undefined.

Early errors are nice

Yes, exactly. Errors should fail early and loudly. That's why the strictness of strict mode is useful.

It's no weirder that 123.foo not throwing.

No, it's entirely different, because numbers are object-coercible. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160916/1f132d4a/attachment.html

Would break the web.

On Fri, Sep 16, 2016 at 1:55 AM, Ron Waldon wrote:

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

https://github.com/sebmarkbage/ecmascript-undefined-propagation

Rather than introduce new syntax, Sebastian's proposal was to automatically propagate undefined values: if we're about to throw a dot-property-access-on-undefined error, we just return undefined instead.

I could find much discussion about this here, but I did find lots of discussions about approaches involving alternative syntax.

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20160916/e572b6b3/attachment.html

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

sebmarkbage/ecmascript-undefined-propagation

I could find much discussion about this here, but I did find lots of discussions about approaches involving alternative syntax.

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

https://github.com/sebmarkbage/ecmascript-undefined-propagation

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? :/

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? :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161001/96a2c26d/attachment.html

I disagree with silently ignoring property access on null/undefined.

Early errors are nice

Yes, exactly. Errors should fail early and loudly. That's why the strictness of strict mode is useful.

It's no weirder that 123.foo not throwing.

No, it's entirely different, because numbers are object-coercible.

I disagree with silently ignoring property access on null/undefined.

Early errors are nice

Yes, exactly. Errors should fail early and loudly. That's why the strictness of strict mode is useful.

It's no weirder that 123.foo not throwing.

Would break the web.

On Fri, Sep 16, 2016 at 1:55 AM, Ron Waldon wrote:

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

https://github.com/sebmarkbage/ecmascript-undefined-propagation

Rather than introduce new syntax, Sebastian's proposal was to automatically propagate undefined values: if we're about to throw a dot-property-access-on-undefined error, we just return undefined instead.

I could find much discussion about this here, but I did find lots of discussions about approaches involving alternative syntax.

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161003/e572b6b3/attachment.html

Or !., which unfortunately is now being used by TypeScript?

Or !., which unfortunately is now being used by TypeScript? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/8245b89c/attachment.html

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/5c940dac/attachment.html

Le 13 oct. 2016 à 14:37, Kagami Rosylight <saschanaz at outlook.com> a écrit :

Or !., which unfortunately is now being used by TypeScript?

What is exactly the issue you're trying to solve? The token ?. works fine (technically with a simple lookahead for excluding digit after it).

Le 13 oct. 2016 à 14:37, Kagami Rosylight a écrit :

Or !., which unfortunately is now being used by TypeScript?

What is exactly the issue you're trying to solve? The token ?. works fine (technically with a simple lookahead for excluding digit after it). —Claude

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/60f98eff/attachment.html

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

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

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:

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/99c16df2/attachment-0001.html

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:

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/7122b3ff/attachment.html

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.

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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/27365992/attachment.html

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 at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/45b26a6a/attachment.html

Le 13 oct. 2016 à 17:14, Kagami Rosylight <saschanaz at outlook.com> a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

Concerning your suggestion of using !: From a technical point of view, using ![ instead of ?.[ may work only if you forbid a line terminator before the !, because the following program is valid as of today (with implied semicolons):

foo
![42]

I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

foo
![42]

I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

—Claude

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/44e5d20a/attachment-0001.html

Le 13 oct. 2016 à 17:32, Isiah Meadows <isiahmeadows at gmail.com> a écrit :

It may be a good idea to create a pull request for it if it isn't listed yet

I've already tried some time ago: tc39/ecma262#340

Le 13 oct. 2016 à 17:32, Isiah Meadows a écrit :

It may be a good idea to create a pull request for it if it isn't listed yet

I've already tried some time ago: https://github.com/tc39/ecma262/pull/340

—Claude -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/b334e0e1/attachment.html

Why is this needed? Why are people trying to get the property of an object which is null? Why is the object null in the first place? This can probably be considered poor program design. It's sort of like trying to dereference a null pointer. In addition, parameter defaults and defaults in destructuring may make this somewhat less of an issue.

Note that TS2 is explicitly moving away from permitting null to be assigned to something which is alleged to be an object. (Although TS2 has "stolen" the ! operator, it is merely a type assertion--a narrowing from object | null to object as I understand it. It is not a run-time check.)

But let's say we nevertheless think this is an important feature. It has been discussed at great length here. No proposal has ever had the inevitability, generality, or intuitiveness that would allow it to gain traction. All the proposals are essentially little syntactic hacks.

Can we find some more general extension to JS syntax that solves or mitigates this problem as well as others? Kills two birds with one stone? One that seems like a natural extension to current syntax, instead of an extra magic character we stick somewhere to solve one specific problem?

Just as an example, consider the following idiom for null propagation:

a ? a.b ? a.b.c : undefined : undefined

We can leverage this pattern by allowing the : in the ternary operator to be omitted (defaulting to undefined), allowing us to write:

a ? a.b ? a.b.c

Whether you love it or hate it, at least this solves more problems that just null propagation. I'm not seriously suggesting this. I'm just saying we need to be more creative in brainstorming possible solutions to the problem.

-- Bob

Just as an example, consider the following idiom for null propagation:

a ? a.b ? a.b.c : undefined : undefined

We can leverage this pattern by allowing the : in the ternary operator to be omitted (defaulting to undefined), allowing us to write:

a ? a.b ? a.b.c

-- Bob

On Thu, Oct 13, 2016 at 9:37 PM, Claude Pache <claude.pache at gmail.com> wrote:

Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

Concerning your suggestion of using !: From a technical point of view, using ![ instead of ?.[ may work only if you forbid a line terminator before the !, because the following program is valid as of today (with implied semicolons):
foo
![42]
I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

—Claude

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/59b16bf3/attachment.html

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”

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

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

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”

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

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

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/fa93b4e0/attachment-0001.html

I think the point is that people would like to write something like this:

if (person?.address?.zipcode)

instead of this:

if (person && person.address && person.address.zipcode)

That appeals to me.

I think the point is that people would like to write something like this:

if (person?.address?.zipcode)

instead of this:

if (person && person.address && person.address.zipcode)

That appeals to me.

On Thu, Oct 13, 2016 at 12:20 PM, Bob Myers wrote:

Why is this needed? Why are people trying to get the property of an object which is null? Why is the object null in the first place? This can probably be considered poor program design. It's sort of like trying to dereference a null pointer. In addition, parameter defaults and defaults in destructuring may make this somewhat less of an issue.

Note that TS2 is explicitly moving away from permitting null to be assigned to something which is alleged to be an object. (Although TS2 has "stolen" the ! operator, it is merely a type assertion--a narrowing from object | null to object as I understand it. It is not a run-time check.)

But let's say we nevertheless think this is an important feature. It has been discussed at great length here. No proposal has ever had the inevitability, generality, or intuitiveness that would allow it to gain traction. All the proposals are essentially little syntactic hacks.

Can we find some more general extension to JS syntax that solves or mitigates this problem as well as others? Kills two birds with one stone? One that seems like a natural extension to current syntax, instead of an extra magic character we stick somewhere to solve one specific problem?

Just as an example, consider the following idiom for null propagation:
a ? a.b ? a.b.c : undefined : undefined
We can leverage this pattern by allowing the : in the ternary operator to be omitted (defaulting to undefined), allowing us to write:
a ? a.b ? a.b.c
Whether you love it or hate it, at least this solves more problems that just null propagation. I'm not seriously suggesting this. I'm just saying we need to be more creative in brainstorming possible solutions to the problem.

-- Bob

On Thu, Oct 13, 2016 at 9:37 PM, Claude Pache <claude.pache at gmail.com> wrote:
Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

Concerning your suggestion of using !: From a technical point of view, using ![ instead of ?.[ may work only if you forbid a line terminator before the !, because the following program is valid as of today (with implied semicolons):
foo
![42]
I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

—Claude

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

-- R. Mark Volkmann Object Computing, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161013/7c6978b9/attachment.html

Le 13 oct. 2016 à 19:20, Bob Myers <rtm at gol.com> a écrit :

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

This is not about trying to get something from null, but about taking different paths according to when a reference is null or not without needing to assign to temporary variables, writing complete if structures, and/or repeating oneself.

(...)

Just as an example, consider the following idiom for null propagation:
a ? a.b ? a.b.c : undefined : undefined
We can leverage this pattern by allowing the : in the ternary operator to be omitted (defaulting to undefined), allowing us to write:
a ? a.b ? a.b.c
Whether you love it or hate it, at least this solves more problems that just null propagation. I'm not seriously suggesting this. I'm just saying we need to be more creative in brainstorming possible solutions to the problem.

You can already writea && a.b && a.b.c in JS... but you still have to repeat a thrice andb twice, which is an issue if a and b are complex or lengthy expressions. Sometimes I am tempted to write something in the lines of (_ = a.b) && _.c in order to avoid the issue, but it is less readable.

Here is a more complex although somewhat contrived example: If an element named "foo" is inside a

section, open the latter in order to reveal the former:

document.querySelector("input[name=foo]")?.closest(".details")?.open = true

(The short-circuiting mechanism, which is an important part of the semantics in my proposal, ensures that the assignment is performed only when the expressions just before the ?s are not null/undefined.)

Le 13 oct. 2016 à 19:20, Bob Myers a écrit :

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

(...)

Just as an example, consider the following idiom for null propagation:
a ? a.b ? a.b.c : undefined : undefined
We can leverage this pattern by allowing the : in the ternary operator to be omitted (defaulting to undefined), allowing us to write:
a ? a.b ? a.b.c
Whether you love it or hate it, at least this solves more problems that just null propagation. I'm not seriously suggesting this. I'm just saying we need to be more creative in brainstorming possible solutions to the problem.

Here is a more complex although somewhat contrived example: If an element named "foo" is inside a

section, open the latter in order to reveal the former:

document.querySelector("input[name=foo]")?.closest(".details")?.open = true

—Claude

On Thu, Oct 13, 2016, 12:07 Claude Pache <claude.pache at gmail.com> wrote:

Le 13 oct. 2016 à 17:14, Kagami Rosylight <saschanaz at outlook.com> a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

I agree with both points here. It's not very pretty, and it's also inconsistent with the rest of the language. I was just clarifying what I believed to be the primary contender, independent of bias.

foo
![42]

I want to like the idea, 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. I'm not sure I like the syntax in either form (it has at least the ability to be non-ambiguous).

I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

On Thu, Oct 13, 2016, 12:07 Claude Pache <claude.pache at gmail.com> wrote:

Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit :

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?

The issue with ?.[ is that it is considered as not pretty by some people. A syntax that is at the same time pretty, technically working, and not confusing is difficult to find.

I agree with both points here. It's not very pretty, and it's also inconsistent with the rest of the language. I was just clarifying what I believed to be the primary contender, independent of bias.

foo
![42]

I’m curious why this proposal is not even listed in stage 0 proposal list.

Because no representative of TC39 has volunteered to champion it.

—Claude

es-discuss mailing list es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161014/e0c35ab4/attachment-0001.html

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 and it interestingly changes behavior when there is a line break before !.

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. :/

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 and it interestingly changes behavior when there is a line break before !.

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. :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20161014/af9874ca/attachment.html

For me .?. looks more strict. With variations: a.?.b.?.c,a.?(args), a.?[key]. Since I would rather look on it like on something similar to C# extension method (or Scala implicit method), and then in its "full/extended form" it can be

a.$selfOrNullObj().b.$selfOrNullObj().c

Where .$selfOrNullObj(). exactly corresponds to .?. (or in other words .?. might be shortcut for .$selfOrNullObj().)

And in terms of extension method this-argument not required to be not-null (it is valid case when null passed in place of this-argument into that static method which is extension method for some other class).

Then in this case (inspired by that approach) it can be approximately declared like:

obj.?

<==>

obj.$selfOrNullObj()

<==>

(obj != null ? obj : {_proto_:null} )
// or (obj != null ? obj : ()=>{}) to be compatible with ``a.?(args)``

Then it also could be proposed some variation with fallback to particular default, like

obj.$selfOrDefault(defObj)

<==>

obj.??(defObj)

<==>

(obj != null ? obj : defObj )

Combining with Nil approach (some null object which semantically the same as null, but returns itself for any operation - ., [], (); can be easily implemented as Proxy object for ()=>{}), we can achieve some sort of transitiveness

a.??(nil).b.c.d.??(null)

But in general it fails if for example a.b != null but a.b.c == null, and in this case this construct should work in more advanced way - like, default value should be used not only for that particular.??(Nil). operation, but for all consequent . operations too, until that default value will not be reset back to null by trailing.??(null) operation (which also should replace nil with null).

For me .?. looks more strict. With variations: a.?.b.?.c, a.?(args), a.?[key]. Since I would rather look on it like on something similar to C# extension method (or Scala implicit method)), and then in its "full/extended form" it can be

a.$selfOrNullObj().b.$selfOrNullObj().c

Where .$selfOrNullObj(). exactly corresponds to .?. (or in other words .?. might be shortcut for .$selfOrNullObj().)

Then in this case (inspired by that approach) it can be approximately declared like:

obj.?

<==>

obj.$selfOrNullObj()

<==>

(obj != null ? obj : {_proto_:null} )
// or (obj != null ? obj : ()=>{}) to be compatible with ``a.?(args)``

Then it also could be proposed some variation with fallback to particular default, like

obj.$selfOrDefault(defObj)

<==>

obj.??(defObj)

<==>

(obj != null ? obj : defObj )

Combining with Nil approach (some null object which semantically the same as null, but returns itself for any operation - ., [], () ; can be easily implemented as Proxy object for ()=>{}), we can achieve some sort of transitiveness

a.??(Nil).b.c.d.??(null)

But in general it fails if for example a.b != null but a.b.c == null, and in this case this construct should work in more advanced way - like, default value should be used not only for that particular .??(Nil). operation, but for all consequent . operations too, until that default value will not be reset back to null by trailing .??(null) operation (which also should replace Nil with null). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20170103/01778d67/attachment.html