[swift-evolution] Pitch: Soft unwrapping of optionals

[Patrick Smith]

Ha great stuff Basem! Glad we could help :) Look forward to your next proposal!

> On 11 May 2016, at 11:17 PM, Basem Emara <contact at basememara.com> wrote:
> 
> Thanks for the input everybody, and for the deeper analysis, Rod.
> 
> It’s set straight in my mind now and have even a greater appreciation of optionals than before thanks to this discussion. Let’s scrape this pitch :)
> 
> Happy coding! -Basem
> 
>> On May 11, 2016, at 9:10 AM, Rod Brown <rodney.brown6 at icloud.com> wrote:
>> 
>> I think what you’re referring to as default values would be what you get if you initialize the type directly.
>> 
>> eg:
>> let integer = Int()       // integer = 0
>> let string	 = String() // string = “”
>> let bool 	 = Bool() 	 // bool = false
>> 
>> That said, I’m going to -1 this proposal as well.
>> 
>> The issue I see here is that the proposal conflates a reasonable initialization value with a “go-to default”, which is part of what Swift very deliberately did away with from Objective-C.
>> 
>> Optional should not imply any internal value to the type. It’s the nature of them to be an internal unknown value, or nil, that must be unwrapped deliberately for the protection of your code’s logic. This seems to me to be a slippery slope to the very thing optionals are trying to avoid: default values based on the “zero / bool” conflation.
>> 
>> Additionally, what would that pattern mean for types that cannot be initialised without parameters? If your proposal cannot support anything well beyond the most primitive types, I suspect it doesn’t scale well and shouldn’t come into the language.
>> 
>> If you wish to use defaulting values, it’s best that you specify them instead of hoping the language specifies the one that you assume it will. Do this with the nil coalescing operator (??):
>> 
>> print(temp ?? “”)
>> if myString?.isEmpty ?? true {…}
>> if myBool ?? false {…}
>> if (myInt ?? 0) > otherInt {…}
>> 
>> This is only slightly more code, but it removes all your assumptions, and means you are now the specifier in your code’s logic. You can see from the code exactly what nil will do, and what effect it had on your code.
>> 
>> - Rod
>> 
>> 
>> 
>>> On 11 May 2016, at 10:26 PM, Basem Emara via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Maybe I’m missing something, but aren’t these the default values of primitives deep in the language?
>>> String = “”
>>> Int = 0
>>> Boolean = false
>>> 
>>> So if you needed a different default value for your code, you’d do:
>>> if !myBool?! {…} //Default to true in my app
>>> 
>>> You can still do which is better:
>>> if myBool ?? true {…}
>>> 
>>> Probably booleans is not a clear gain, but for strings it would have vast conveniences.
>>> 
>>>> On May 11, 2016, at 8:20 AM, Patrick Smith <pgwsmith at gmail.com> wrote:
>>>> 
>>>> I actually think this is less safe. It depends on the situation for what value the default should be. Sometimes it will be false, other times it will be true. So far better to explicitly show what the default is.
>>>> 
>>>> 
>>>>> On 11 May 2016, at 10:16 PM, Basem Emara via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> Forcing unwrapping of optionals is bad practice, but safely unwrapping can be tedious. I’m hoping for something in between that would that would provide soft unwrapping using a syntax like: myVar?!
>>>>> 
>>>>> For example, currently we have to do this:
>>>>> 
>>>>> let temp = (myString ?? “”); print(“\(temp)”)
>>>>> if (myString ?? “”).isEmpty {…}
>>>>> if myBool ?? false {…}
>>>>> if (myInt ?? 0) > otherInt {…}
>>>>> 
>>>>> To something like this instead:
>>>>> 
>>>>> print(“\(temp?!)”)
>>>>> if myString?!.isEmpty {…}
>>>>> if myBool?! {…}
>>>>> if myInt?! > otherInt {…}
>>>>> 
>>>>> What this is implying is that it will attempt to unwrap or use the default of the type.
>>>>> 
>>>>> Of course, this will only work with primitive types and leverage their implicit default values which would go a long way with tedious code and more safety (less forced unwrapping in the world). Otherwise it will produce a compile error if doing something like: myCustomType?!. What do you think?
>>>>> 
>>>>> Basem
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> 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
>> 
>