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?
The immediate problem I see with your suggestion is the reason why
optionals in Swift are pretty damned awesome: Swift doesn't have default
values. A Bool is not false by default; the Swift compiler will complain if
you don't initialise a Bool variable with a value, one way or the other.
The idea of combining an 'if' with a 'soft unwrap' such that if the unwrap
is nil, the 'if' fails, though - that may have merit.
···
On Wed, May 11, 2016 at 1: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?
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?
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@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?
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 <pgwsmith@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?
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@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@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@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?
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@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@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@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@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?
I too agree the unwrapping process can be tedious but I believe this is
best because it forces us to check we're doing the right thing in code and
prevents a lot of errors we have to keep on checking in more dynamic
languages. -1 from me too.
- Leonardo
···
On 11 May 2016 at 10:19, Patrick Smith via swift-evolution < swift-evolution@swift.org> wrote:
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@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@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@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@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
>>
>