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 <pgwsm...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution