Also, without a leading token, a selector expr with the optional chaining operator inside a ternary operator would be ambiguous. ``` const contactSelector = true ? .contacts.email : .contacts.phone; ```
From: Isiah Meadows Sent: 27 June 2019 19:18 To: Michael Luder-Rosefield Cc: Simon Farrugia; es-discuss Subject: Re: Re: Proposal: Selector/Select Expression Generalize this far enough, and you wind up with something not far from this: https://github.com/tc39/proposal-partial-application ----- Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Wed, Jun 26, 2019 at 5:44 AM Michael Luder-Rosefield <rosyatran...@gmail.com> wrote: > > The more I read this proposal, the more I feel the ideal solution is a > preceding 'wildcard' character, to stand-in for a generic argument. If it > wasn't in (widespread!) use, I'd suggest an underscore: ```const f = _.prop > ``` > > Since it is, though, we need another one. How about a double-colon, seeing as > it can represent property access on other languages? ```const f = ::prop ```, > ```const g = ::[compProp] ```, ```const h = ::?optProp ``` > > On Sun, 23 Jun 2019, 11:43 Simon Farrugia, <simonfarrugi...@gmail.com> wrote: >> >> I was expecting that someone brings up the brackets property accessor at >> some point. >> I would argue that there is a bit of syntactic inconsistency since usually >> when using the bracket accessors it is not preceded by a dot. >> ``` >> const getEmail = user => user["contacts"].email; // No dot between user & >> ["contacts"]. >> const getEmail = .["contacts"].email; >> ``` >> Having said that, the currently proposed Optional Chaining operator (Stage >> 2) does exactly that and more: >> ``` >> obj?.prop // optional static property access >> obj?.[expr] // optional dynamic property access >> func?.(...args) // optional function or method call >> ``` >> So I'd say that there is consistency with what is currently being proposed. >> >> Regarding the Optional Chaining operator, which precedes the dot. How would >> that work? >> >> It would have to be something like this, if allowed. >> ``` >> >> const getEmail = user => user?.contacts.email; >> const getEmail = ?.contacts.email; >> >> ``` >> >> It does look odd at first, but it’s quite simple is you think about it. We >> are just omitting the initial part of the expression. >> >> >> >> More Examples with Optional Chaining operator: >> >> ``` >> >> // With optional dynamic property access. >> >> const getUserEmail = user => user?.["contacts"].email; >> const getUserEmail = ?.["contacts"].email; >> >> >> >> // With optional function or method call. >> >> const getJohnsEmail = getUserContacts => getUserContacts?.("John").email; >> const getJohnsEmail = ?.("john").email; >> >> ``` >> >> >> >> The beauty of what is being proposed is that there is nothing new to learn >> or any new weird operator introduced. >> >> Any weirdness one might find with the expressions above will already have >> been introduced by the Optional Chaining operator. >> >> The only thing this does is to allow you to omit the initial (redundant) >> part of the expression. >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
