[swift-evolution] Brainstorming: Optional sugar inferred map

[Paul Ossenbruggen]

> On Feb 15, 2016, at 12:22 PM, Haravikk <swift-evolution at haravikk.me> wrote:

> -1 from me as it means that a complex statement with a single question marked variable could in fact be an entirely optional statement. While I dislike the boilerplate as well, I think it’s much better to have the explicit conditional branch there to make it absolutely clear that a statement is being executed in one case and not in another.


We frequently use  optional chaining, where you get an optional result. How is this different?

> I appreciate the intent of the proposal though, I just think it’s not the right solution as it could make code less readable as I feel it’s better to be explicit with cases such as these IMO.


I am puzzled as to how it is less readable than the examples using “if let” and map, this seems far more readable to me. 

> Also, I don’t like the nil-coalescing operator changes, as it seems to contradict the normal form where the right hand side is the fallback value, not the intended result. It’d be better to have some kind of non-nil operator, but personally I don’t think it’s worth it.


For nil-coalescing changes, while I see your point, i don’t see why we should constrain it to that usage model only, if it can be made more powerful and easier to read than map. This is essentially syntactic sugar for map on an optional.  Currently it is possible to do this: 

a ?? doSomething(59)

it is not a huge stretch to allow the result of the left hand optional expression on the right hand side:

	    a ?? doSomething($$)

The more advanced things like multiple statements in closure, or tuple are certainly up for discussion or could even be a future addition, if there is demand.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/d8c6f763/attachment.html>