[swift-evolution] Proposal: Replace ?? by an (optional) argument to ?

Thorsten Seitz tseitz42 at icloud.com
Sat Jan 30 05:41:01 CST 2016


Hi Amir,

I confess that I’m not really understanding what you don’t like about the operator ??.

Personally I find it very clear and read it as „or else“. The only worthwhile alternative to ?? would be a method on Optional called `orElse()` like e.g. Java has which expresses the notion quite clearly but with a bit more visual clutter than ??:

(x?.isEmpty).orElse(false)		// same as x?.isEmpty ?? false

Besides having less visual clutter I see another advantage to the operator ??: when I want to do something similar on the level of functions of type T -> U? instead of values of type U? I could define an operator ??? which works similar to ??
This would not be possible with a method orElse() because AFAIK it is not possible to add methods to functions.
(This idea relates to the thread about having first class partial functions).

Example:

infix operator ??? {}

func ???<T,U>(lhs: T -> U?, rhs: T -> U?) -> T -> U? {
    func result(x: T) -> U? {
        if let res = lhs(x) {
            return res
        }
        else {
            return rhs(x)
        }
    }
    return result
}

func isEven(x: Int) -> String? {
    switch x {
    case x where x % 2 == 0: return "\(x) is even"
    default: return nil
    }
}

func isOdd(x: Int) -> String? {
    switch x {
    case x where x % 2 == 1: return "\(x) is odd"
    default: return nil
    }
}

let f = isEven ??? isOdd

f(3) // => "3 is odd"


-Thorsten



> Am 29.01.2016 um 17:58 schrieb Amir Michail via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> On Jan 29, 2016, at 9:25 AM, Ross O'Brien <narrativium+swift at gmail.com <mailto:narrativium+swift at gmail.com>> wrote:
>> 
>> What about it?
>> 
>> "x ?? false" is simple. If x isn't nil, return x; if x is nil, return false.
>> "x?.isEmpty ?? false" again is already readable; if x isn't nil, return x.isEmpty; if x is nil, return false.
>> 
>> "Bool(x?.isEmpty)" seems be suggesting that the Bool type has a failable initialiser "init?(_: Bool?)". If x is nil, x.isEmpty would be nil, so the resulting Bool would be nil, not false - this code returns a Bool?, which you already had.
>> 
> 
> How about this:
> 
> if? !x?.isEmpty { … } // if? nil { … } = if false { … }
> while? !x?.isEmpty { … }
> etc.
> 
>> "??(false, x?.isEmpty)" ... uses an operator as an identifier, for a start. At best I'd try to interpret this like reduce - take a collection or variadic list of optionals, return the value of the first non-nil else return the "default". Except I'd still put the default at the end, because I can't think why it would be at the start.
>> 
>> So, if the given problem is taking the nil-coalescing and putting it up front, perhaps there should be a global generic function:
>> 
>> func firstNonOptional<T>(possibles:T?..., failsafe:T) -> T
>> {
>>     return possibles.reduce(nil, combine:{ $0 ?? $1 }) ?? failsafe
>> }
>> 
>>  
>> 
>> On Fri, Jan 29, 2016 at 1:48 PM, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jan 29, 2016, at 8:42 AM, Craig Cruden <ccruden at novafore.com <mailto:ccruden at novafore.com>> wrote:
>>> 
>>> still much worse.
>>> 
>> 
>> What about: Bool(x?.isEmpty) // nil and false => false
>> 
>>> 
>>>> On 2016-01-29, at 20:41:06, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Jan 29, 2016, at 5:03 AM, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>>>>> 
>>>>> I agree with Erica. The ?? operator is very readable IMO.
>>>>> 
>>>>> Furthermore x?(false).isEmpty looks like it would evaluate false.isEmpty when x is nil which is certainly not what is intended.
>>>> 
>>>> What about this then: ??(false, x?.isEmpty)
>>>> 
>>>>> In addition it would not be clear which default should be used in case of multiple optional chainings happening, i.e. what should be the result of person?(false).address?.(true).isEmpty
>>>>> 
>>>>> -Thorsten
>>>>> 
>>>>> 
>>>>> Am 26. Januar 2016 um 03:29 schrieb Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>>>> 
>>>>>> Not loving this. I'm quite happy with ??-coalescing and don't see
>>>>>> a compelling reason it needs to be "cleaner". I find your suggested
>>>>>> enhancement less readable. Looks like an optional chaining across 
>>>>>> a function.
>>>>>> 
>>>>>> -- E
>>>>>> 
>>>>>>> On Jan 25, 2016, at 7:03 PM, Amir Michail via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> 
>>>>>>> Examples:
>>>>>>> 
>>>>>>> * instead of x ?? false, you would have x?(false)
>>>>>>> * instead of x?.isEmpty ?? false, you would have x?(false).isEmpty
>>>>>>> 
>>>>>>> I think this change would result in cleaner looking code.
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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>
>>>> 
>>>> _______________________________________________
>>>> 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>
>> 
>> 
> 
> _______________________________________________
> 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/20160130/0163640d/attachment.html>


More information about the swift-evolution mailing list