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@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 <pgwsm...@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@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@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
