[swift-evolution] Make distinction between ?? -> T and ?? -> T?

[Sébastien Blondiau]

The situation in which I found a little confusing that that was the same operator, was something like that:

func someFunction() -> T {
    
    var someValue: T
    
    /* some code */
    
    var value = someOptionalValue ?? someValue
    
    /* some code */
    
    return value
}

For some reasons, I had to consider a new case where someValue had to be an optional

func someFunction() -> T {
    
    var someValue: T?
    
    /* some code */
    
    var value = someOptionalValue ?? someValue
    
    /* some code */
    
    return value	// error: value of optional type 'T?' not unwrapped; did you mean to use '!' 
}

In my point of view, the error was not at the return line but rather at the declaration of value. The existence of two operators would have forced me in the first case to use ?! to have value as a non optional, and would make the localisation of the error obvious.

The operator ?! have to have a lower precedence to return the non optional value after that ?? returned the optional one.
Having two operators would not prevent programmers from chaining. The case:

var value = someArray ?? someFallback ?? secondaryFallback ?? []

would just be replaced by:

var value = someArray ?? someFallback ?? secondaryFallback ?! []

Same changes would occur everywhere value is non optional. With these changes, I don't see any situation where code would be broken.

--
Sébastien Blondiau

> Le 7 mars 2016 à 23:53, Ross O'Brien <narrativium+swift at gmail.com> a écrit :
> 
> During the review of the proposal for a '??=' operator, one of the given disadvantages was the confusion over the meaning of '??'. Since one of its two meanings is that it nil-coalesces a chained expression into a non-optional result, it might be misinterpreted that given the expression 'lhs ??= rhs' and a non-optional 'rhs', 'lhs' would no longer be optional. '??' is an overloaded operator; unloading one of its two responsibilities to a second operator would improve code clarity.
> 
> Radoslaw's example is simplistic because '[]' is unambiguously non-optional. So let's replace it:
> 
> var value = someArray ?? someFallback ?? secondaryFallback ?? tertiaryFallback
> 
> Is 'value' optional or non-optional?
> 
> var value = someArray ?? someFallback ?? secondaryFallback ?! tertiaryFallback
> 
> Now we can see immediately that 'value' is optional in the first case, and non-optional in the second. However, since '!' is associated with assertions, I agree that perhaps there's a better choice of operator for this meaning.
> 
> 
> On Mon, Mar 7, 2016 at 10:26 PM, Radosław Pietruszewski <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> -1, never seen a real world situation where this would be confusing/problematic.
> 
> Having one operator is nice for chaining:
> 
> var value = someArray ?? someFallback ?? secondaryFallback ?? []
> 
> — Radek
> 
>> On 07 Mar 2016, at 22:29, Sébastien Blondiau via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Currently, there is only one nil coalescing operator, which may return an optional value or not, depending on the second parameter. This variability can leads to unclear line of code:
>> 
>> var isItOptionalOrNot = value ?? otherValue
>> 
>> I think there should be two distinct operators:
>> 
>> var certainlyOptional = value ?? otherValue
>> var certainlyNotOptional = value ?! notOptionalValue
>> 
>> In my point of view, this differentiation brings more clarity about wether the result is an optional or not.
>> 
>> What's your opinion?
>> 
>> --
>> Sébastien Blondiau
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

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