On Thu, Mar 10, 2016 at 9:23 AM Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:
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@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 ?? tertiaryFallbackvar 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@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