It’s worth mentioning that the problem this thread is discussing can be generalized to idioms / applicative. The specific case here is for Optional but many other types could benefit from an elegant syntactic solution to this problem. It might be worth exploring a more general solution. Here’s a link to how this is handled in Idris: http://docs.idris-lang.org/en/latest/tutorial/interfaces.html#idiom-brackets <http://docs.idris-lang.org/en/latest/tutorial/interfaces.html#idiom-brackets>.
Matthew > On Dec 11, 2017, at 12:01 PM, Jared Khan via swift-evolution > <swift-evolution@swift.org> wrote: > > 1. Correct > > 2. It felt natural to me. It’s analogous to the existing optional chaining > scenarios and composes nicely. I think it’s about as understandable as > existing chaining, a newbie would have to look it up to discover its meaning. > What are your thoughts on this particular syntax (ignoring 3. momentarily)? > Hopefully others in this thread can share their views too. > As for how common I’d expect it to be, it’s something I’ve run into myself a > few times. Again, I hope members of this list can give their view on if this > would be useful to them. > > 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has > never been available as a postfix operator. Perhaps I’m missing your point, > could you demonstrate where it is allowed? > > Best, > Jared > >> On 11 Dec 2017, at 17:07, Magnus Ahltorp <m...@kth.se> wrote: >> >> >>> 12 Dec. 2017 01:30 Jared Khan via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> I'd like to propose a syntax addition that acts to ease some things that I >>> believe should fall under the umbrella of 'optional chaining'. Optional >>> chaining allows us to access the properties of an optional value and return >>> nil if any link in that chain breaks. I propose we introduce syntax to >>> allow similar chaining when passing optional valued parameters to functions >>> that expect that parameter to be non-optional. >> >> 1. Am I right in assuming that you propose that the suffix operator "?" >> would make the result of the surrounding method/function call optional, so >> that a(b(c?)) would make the result of the "b" function call optional, but >> not the "a" function call, and that it would be a(b(c?)?) if we would like >> to propagate this two levels? >> >> 2. If that is the case, is that understandable/neat enough? How common would >> you expect this to be? >> >> 3. For some reason, (in current Swift) the suffix operator "?" seems to be >> allowed in intra-expression syntax, and only fails when the inter-expression >> syntax is checked for optionality congruence. Is there a reason for this? I >> would have expected that the congruence error "cannot use optional chaining >> on non-optional value of type" would never be seen for a lone "?", since the >> error message "'?' must be followed by a call, member lookup, or subscript" >> would always be displayed first if it was checked first. The "." operator >> checks intra-expression syntax first, before checking congruence. Is this a >> sign that "?" as a suffix operator is already somewhat operational as an >> operator for optional types? I have a faint recollection that it was doing >> something in earlier versions of Swift. >> >> /Magnus >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
