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 < [email protected]> 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 <[email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 > >>>>> [email protected] > >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>>> > >>> > >>> _______________________________________________ > >>> swift-evolution mailing list > >>> [email protected] > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >> > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
