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
