[swift-evolution] Brainstorming: Optional sugar inferred map

[Haravikk]

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

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.

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.

> On 15 Feb 2016, at 17:45, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Feb 15, 2016, at 12:49 AM, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> The ? operator is unwrapped and the appendContentsOf method is only executed if the value is non-nil. However you can not do the following, which seems natural:
>> 
>> a? + b
> 
> FWIW, "a?” is the degenerate form of the optional chaining operation, which tests A, conditionally extracts its value, then re-wraps it back up without performing any other operations on it.  It is equivalent to “a?.identity()”.  The compiler rejects it because it is confusing/surprising for people, not because it is undefined.
> 
> I would be very concerned with defining this operation to mean something else, because that introduces inconsistency and a completely different kind of surprise to the language.
>> 
>> To address this, the nil-coalescing operator would allow $$, where $$ is the unwrapped unnamed result of the expression when non nil: 
> 
> Just to point one thing out, ?? is an operator in the stdlib.  Doing something like this would require baking it into the compiler.
> 
> 
> IMO, the problem you’re addressing is already adequately solved by guard.
> 
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/0f92a993/attachment.html>