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

[Jordan Rose]

I forgot to mention it but I'm (also?) very much against adding a new operator with "!" in the name that won't ever trap. The "not" operator got pulled in from C, but every other use of "!" means "I am asserting I know more than the compiler does" (or perhaps more accurately "there is a precondition here that the compiler doesn't know about"). That includes !-to-unwrap, ImplicitlyUnwrappedOptional, 'as!', and 'try!'.

Jordan


> On Mar 10, 2016, at 4:49 , Sébastien Blondiau via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Here is my proposal:
> 
> Distinction between ?? -> T? and ?? -> T
> 
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#introduction>Introduction
> 
> The current nil coalescing operator can return an optional or not, depending on the second parameter.
> 
> The prosposed solution is the use of two distinct operators: ?? and ?!.
> 
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#motivation>Motivation
> 
> Currently, the only nil coalescing operator may return an optional value or not. This variability can leads to unclear line of code:
> 
> var result = value ?? otherValue
> where result may be an optional, and cannot be determined without looking for the definition of otherValue.
> 
> A real situation where I found the unique operator confusing 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 situation, the error was not at the return line but rather at the declaration of value. value was non optional in the first code and implicitly became optional in the second code.
> 
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#proposed-solution>Proposed solution
> 
> A new operator ?! , which take a non optional second parameter and return a non optional value. This new operator replaces the current ?? which return a non optional.
> 
> This ensures the programmer knows if whether the value is optional or not:
> 
> var value = someOptionalValue ?? someValue  // value is optional, without depending on someValue optionality
> 
> var value = someOptionalValue ?! someValue  // value is not optional
> // but if someValue is optional then this produces an error
> The nil coalescing chaining benefits the same clarity:
> 
> var optionalValue    = someArray ?? someFallback ?? secondaryFallback ?? tertiaryFallback
> var nonOptionalValue = someArray ?? someFallback ?? secondaryFallback ?! tertiaryFallback
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#detailed-design>Detailed design
> 
> Under this proposal, the ?! operator has a lower precedence than ?? to have the described form of chaining: the operator ?! returns a non optional after that ?? has returned an optional.
> 
> infix operator ?? { associativity right precedence 131 }
> 
> +infix operator ?! { precedence 130 }
> The ?! operator is non associative to avoid bad usages, which would lose some interest of the new operator:
> 
> -var nonOptionalValue = someArray ?! someFallback ?! secondaryFallback ?! tertiaryFallback
> +var nonOptionalValue = someArray ?? someFallback ?? secondaryFallback ?! tertiaryFallback
> Only the function ?? which returns a non optional is replaced:
> 
> -public func ??<T>(optional: T?, @autoclosure defaultValue: () throws -> T) rethrows -> T
> +public func ?!<T>(optional: T?, @autoclosure defaultValue: () throws -> T) rethrows -> T
> The internal implementation do not need to change.
> 
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#impact-on-existing-code>Impact on existing code
> 
> This proposal will impact every code using the nil coalesing operator to get a non optional value.
> 
> The migration can be done automatically by replacing all ?? which currently return non optional value.
> 
>  <https://github.com/HyperSeb/nil-coalescing-operator/tree/master#alternatives-considered>Alternatives considered
> 
> There are currently no alternatives considered.
> 
> Thoughts?
> 
> --
> Sébastien Blondiau
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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