[swift-evolution] Pitch: Soft unwrapping of optionals

[Leonardo Pessoa]

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 at 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 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
> >>
> >
>
> _______________________________________________
> 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/20160511/abfd1741/attachment.html>