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
