Re: Existential Operator / Null Propagation Operator

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](https://msdn.microsoft.com/en-us//library/bb383977.aspx) (or [Scala implicit method]( http://docs.scala-lang.org/overview

Re: Re: Existential Operator / Null Propagation Operator

>From a technical point of view, using  and it interestingly changes be

Re: Existential Operator / Null Propagation Operator

On Thu, Oct 13, 2016, 12:07 Claude Pache 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

Re: Existential Operator / Null Propagation Operator

> 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? This is not about trying to get something from null, but about taking different paths according to when a

Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

>Why is this needed? Why are people trying to get the property of an object >which is null? I will appreciate null propagation when a function receives an “option bag” ```js function someFunction(options) { if(options?.foo) { doSomething(); }; } someFunction(); someFunction({ foo: true

Re: Existential Operator / Null Propagation Operator

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 destructu

Re: Existential Operator / Null Propagation Operator

> 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___ es-discuss mailing list es-dis

Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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 looki

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

er the ambiguity is real or not. For example, from [an > earlier post of this thread]( > https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44 > ): > > > > >But what should be done with cases like obj?[1]?[2]:[3]. > > > > A formatter

Re: Re: Existential Operator / Null Propagation 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](https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44): &

Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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 o

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

Is the only problem here is the parser problem with `obj.prop?.2:.1`? Then how about `??. ` instead of `?.`? >Once upon a time, there was a fascinating proposal on this subject: Why are you posting twice? :/ ___ es-discuss mailing list es-discuss@mozi

Re: Existential Operator / Null Propagation Operator

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 prop

Re: Existential Operator / Null Propagation Operator

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 ar

Re: Existential Operator / Null Propagation Operator

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

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

> Le 25 août 2016 à 17:17, Claude Pache a écrit : > > >> Le 25 août 2016 à 16:05, Alexander Mekhonoshin > > a écrit : >> >> >> 2. unary ?. >> >> window?.navigator?.toString() >> >> browser: "[object Navigator]" >> node: ReferenceError: window is not defined >>

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

> Le 25 août 2016 à 16:05, Alexander Mekhonoshin a > écrit : > > > > 3. groupped ?.() > Syntax for the full existential chain case: > > .?(a.b.c) // equals with typeof a !== 'undefined' && a.b && a.b.c > In other words, `.?(a.b.c)` (or whatever other syntax) is approximately equivalent to

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

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

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

`??(a.b.c)` is good alternative for `?.(a.b.c)` as shorthand for `?.a?.b?.c` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

// Excuse my beginner’ English I have a few (3) thoughts: 1. binary ?. If a === null: a?.b.c === undefined If a?.b === null: a?.b.c // throws exception If a?.b === null: a?.b?.c === undefined If a === 0: a?.b.c === undefined If a === '': a?.b.c === undefined If a in not defined: a?.b.c // t

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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.

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions. ```js 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 Th

Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

It is a parser problem: obj.prop?.2:.1 You need arbitrary look ahead to disambiguate ?. from ?: solve the problem. On Tue, May 10, 2016 at 10:32 AM, wrote: > Why isn't it possible to use the obj.property?.sub syntax in combination > with lookahead as suggested by Brendan Eich 4 years ago? > >

Re: Re: Existential Operator / Null Propagation 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 ___ es-discuss mailing list es-discuss@mozilla.org

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

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

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

> Le 8 févr. 2016 à 01:16, Bergi a écrit : > > Claude Pache wrote: >> >>> .? >>> (?) >>> [?] >> >> Yes, that syntax is possible. Whether it is preferable is a question of >> taste. Personally, I don’t like it: >> >> * I slightly prefer `?.` over `.?` for the following reason: The `?.` token

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

If we ever hope to include "elvis". obj?:[expr] would be roughly equivalent to: obj != null ? obj : [expr] rather than what you are suggesting here: obj != null ? obj[expr] : undefined; On Sun, Feb 7, 2016 at 4:16 PM, Bergi wrote: > Claude Pache wrote: > >> >> .? >>> (?) >>> [?] >>> >> >>

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

Claude Pache wrote: .? (?) [?] Yes, that syntax is possible. Whether it is preferable is a question of taste. Personally, I don’t like it: * I slightly prefer `?.` over `.?` for the following reason: The `?.` token may be conceptually separated in two, first the question mark which checks

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

_____ Re: Optional Chaining (aka Existential Operator, Null Propagation) From: Kevin Smith Date: 5 Feb, 15:22 To: Claude Pache CC: es-discuss Show quoted text Just curious: what's the rationale for that behavior, as opposed to "deep" short-circuiting? It seems like if I

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

> > In case `myForm.querySelector('select[name=foo]')` is not null, then > `myForm.querySelector('select[name=foo]').selectedOptions` is always an > HTMLCollection and has always a `length` property. If it is not the case, > then either I made a typo, or I am testing some ancient browser that > doe

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

> Le 5 févr. 2016 à 16:22, Kevin Smith a écrit : > > Yes: the `?.` operator does not change the meaning of the subsequent `.` > operator. I like to think of it as: the effect is local (short-circuiting > aside), you are not switching between "modes". It’s a feature. > > Just curious: what's

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

> > Yes: the `?.` operator does not change the meaning of the subsequent `.` > operator. I like to think of it as: the effect is local (short-circuiting > aside), you are not switching between "modes". It’s a feature. > Just curious: what's the rationale for that behavior, as opposed to "deep" sh

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

> Le 4 févr. 2016 à 21:03, Kevin Smith a écrit : > > (...) The syntax still seems problematic, though, from an aesthetic point of > view. > > The `obj ?. prop` form looks natural and aligns well with how this feature > appears in other languages. The other forms are less natural: > > obj?.

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

> Le 4 févr. 2016 à 21:03, Kevin Smith a écrit : > > > That aside, I have a question about the semantics. What does this do: > > ({ x: 1 }).x?.y.z; > > Does it throw a ReferenceError? > Yes: the `?.` operator does not change the meaning of the subsequent `.` operator. I like to think of i

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

Thanks for putting this together. At first glance, I think the semantics look pretty good. The syntax still seems problematic, though, from an aesthetic point of view. The `obj ?. prop` form looks natural and aligns well with how this feature appears in other languages. The other forms are less

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

On Thu, Feb 4, 2016 at 10:06 AM, Claude Pache wrote: > > Le 4 févr. 2016 à 17:47, John Lenz a écrit : > > > [...] > > > Waldemar's example makes the problem obvious but I think we could do use, > which I think is preferable to the proposed: > > .? > (?) > [?] > > > Yes, that syntax is possible.

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

x27;t be accessed with the dot operator currently) and `x?.foo:0`. If we assume the existential operator doesn't allow numerical property access, then `x.?3` is *obviously* an error (not so obvious with `?.`), and we won't expect the ternary operator. Although, `x.?3` also introduces

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

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

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

On Wed, Feb 3, 2016 at 2:41 PM, Claude Pache wrote: > > > Le 3 févr. 2016 à 20:56, John Lenz a écrit : > > > > Can you reference something as to why the more obvious operators are > problematic? > > > > ?. > > That one (that I've used) must work, with the simple lookahead I've put in > the lexic

Re: Specifying the Existential Operator using Abrupt Completion

(Sorry for spam.) For reference in case someone searches for that topic in the archive; see: https://esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation > Le 3 févr. 2016 à 20:28, John Lenz a écrit : > > Did this happen? I would like to see some prog

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

> Le 3 févr. 2016 à 20:56, John Lenz a écrit : > > Can you reference something as to why the more obvious operators are > problematic? > > ?. That one (that I've used) must work, with the simple lookahead I've put in the lexical grammar, in order to continue to parse `x?.3:0` as today. > ?

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

On 02/03/2016 11:56, John Lenz wrote: Can you reference something as to why the more obvious operators are problematic? ?. ?[] ?() ?: Some of these have problems. For example, a?[]:b is already valid ECMAScript syntax and does something else. There is an analogous but subtler problem for

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

Can you reference something as to why the more obvious operators are problematic? ?. ?[] ?() ?: On Fri, Jan 29, 2016 at 7:19 AM, Claude Pache wrote: > Hi, > > I have prepared a strawman for the `?.` operator: > > https://github.com/claudepache/es-optional-chaining/ > > If there is interest in t

Re: Specifying the Existential Operator using Abrupt Completion

bout the right semantics (and the issues) of the >> existential operator. >> >> user.getPlan?().value?.score; >> >> The intended semantics of `?` is that, whenever its LHS evaluates to >> `null` or `undefined`, >> the evaluation of the whole expression (or

Optional Chaining (aka Existential Operator, Null Propagation)

Hi, I have prepared a strawman for the `?.` operator: https://github.com/claudepache/es-optional-chaining/ If there is interest in that proposal, I'm looking for a champion from TC39. Regards, —Claude__

Re: Specifying the Existential Operator using Abrupt Completion

required to distinguish it from conditional expression. > > -- > From: zenpars...@gmail.com > Date: Thu, 14 Jan 2016 15:08:21 + > Subject: Re: Specifying the Existential Operator using Abrupt Completion > To: claude.pa...@gmail.com; ecmascr..

RE: Specifying the Existential Operator using Abrupt Completion

Note that this can possibly complicate the parser as additional effort is required to distinguish it from conditional expression. From: zenpars...@gmail.com Date: Thu, 14 Jan 2016 15:08:21 + Subject: Re: Specifying the Existential Operator using Abrupt Completion To: claude.pa...@gmail.com

Re: Specifying the Existential Operator using Abrupt Completion

> > Since nobody seems to have taken this, I will submit a formal proposal for > stage 0 very soon (before two weeks). > Thanks Claude - looking forward to it! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discus

Re: Specifying the Existential Operator using Abrupt Completion

> Le 13 janv. 2016 à 18:06, C. Scott Ananian a écrit : > > On Wed, May 21, 2014 at 8:33 AM, Claude Pache <mailto:claude.pa...@gmail.com>> wrote: > > I have thought about the right semantics (and the issues) of the existential > operator. > > user.

Re: Specifying the Existential Operator using Abrupt Completion

On Wed, May 21, 2014 at 8:33 AM, Claude Pache wrote: > > I have thought about the right semantics (and the issues) of the > existential operator. > > user.getPlan?().value?.score; > > The intended semantics of `?` is that, whenever its LHS evaluates to > `nul

Re: Existential Operator / Null Propagation Operator

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 wrote: > Le 30 oct. 2015 à 11:11, Isiah Meadows a écrit : > > It's visually ambiguous. I'd rather not read `1

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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 wrote: > > > > Le 30 oct. 2015 à 00:07, Waldemar Horwat a écrit : > > > >> On 10/29/2015 14:20, Claude Pache wrote: > > > >

Re: Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

Ignore that last email...misremembered the context. On Fri, Oct 30, 2015, 06:06 Isiah Meadows wrote: > It's visually ambiguous, though. I really don't want to be reading > `foo..bar()` and `1..toString()` in the same file. They look the same, but > mean two completely different things. > > In a

Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

It's visually ambiguous, though. I really don't want to be reading `foo..bar()` and `1..toString()` in the same file. They look the same, but mean two completely different things. In a language that has this feature, I almost never use it, anyways, unless I'm interacting with the DOM. And even the

Re: Existential Operator / Null Propagation Operator

it your Subject line so it is more specific than "Re: Contents of es-discuss digest..." Today's Topics: 1. Re: Re: Existential Operator / Null Propagation Operator (LaurentiuMacovei) (Isiah Meadows) 2. Re: Existential Operator / Null Propagation Operator

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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

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

} catch (err) { /* ... */ } > // use value without even a basic truthy test > ``` > > On Fri, 30 Oct 2015, 06:07 wrote: > > > -- Forwarded message -- > From: Laurentiu Macovei > To: Sander Deryckere > Cc: "es-discuss@ mozilla.org > list

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

> Le 29 oct. 2015 à 19:32, Eli Perelman a écrit : > > 2 dots may be problematic when parsing numbers (yeah, I know it's probably > not common, but it's still valid): > > 3..toString() > > Eli Perelman Treating `..` as one token would be a breaking change, but I don't think it is a problem i

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

Ron, Javascript only works by `assumptions`, that the developer made at the time the code was written than at runtime they will be the same (and not changing by newly ESX). So, it does NOT make sense to change the code that currently works (expecting to throw error) so that would silently return

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

Macovei mailto:laurentiu.maco...@gmail.com>> To: Sander Deryckere mailto:sander...@gmail.com>> Cc: "es-discuss@ <mailto:es-discuss@mozilla.org>mozilla.org <mailto:es-discuss@mozilla.org> list" mailto:es-discuss@mozilla.org>> Date: Thu, 29 Oct

Re: Existential Operator / Null Propagation Operator

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 ___

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

ed message -- From: Laurentiu Macovei To: Sander Deryckere Cc: "es-discuss@ mozilla.org list" Date: Thu, 29 Oct 2015 19:52:37 +0100 Subject: Re: Re: Existential Operator / Null Propagation Operator Yes! I have updated my answer using markdown and also posted on the original

Re: Re: Existential Operator / Null Propagation Operator

`foo?.bar` and `foo?['bar']` syntax would work too. However the using both current `?` `:` operator and `?.` might be very confusing on the same line. e.g. using `?.` and `?['prop']` ```js var a = { x: { y: 1 } }; var b = condition ? a?.x.?y : a?.y?.z; var c = condition ? a?['x']?['y'] : a?['y']

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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 H

Re: Re: Existential Operator / Null Propagation Operator

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 inhabit

Re: Re: Existential Operator / Null Propagation Operator

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 s

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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 no

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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 err

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

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 >

Re: Existential Operator / Null Propagation Operator

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

Re: Existential Operator / Null Propagation Operator

On 2 June 2015 at 18:57, Brendan Eich wrote: > Sander Deryckere wrote: > >> 2015-06-02 17:49 GMT+02:00 Brendan Eich > bren...@mozilla.org>>: >> >> >> Sander Deryckere wrote: >> >> For the prefix operator, it's unclear to me how you would do >> the following: Say you know `obj`

Re: Existential Operator / Null Propagation Operator

Sander Deryckere wrote: 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`, b

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

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

Re: Existential Operator / Null Propagation Operator

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 Basically, there's a Maybe function which returns a proxy over a target, and returns May

Re: Existential Operator / Null Propagation Operator

> 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 ?., ?(, ?[.

Re: Existential Operator / Null Propagation Operator

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 mo

  1   2   3   4   >