"Removing implicit `nil` initial value for Optional-typed variables"

Evolution Discussion
, , ,
21

Yes, but that's more of a last ditch effort to stop uninitialized reads from becoming exploitable than a recommended setting.

22

I don’t think the LSG has talked about this specifically, so this isn’t an official statement, but I can’t imagine us making this change under our current rubric for Swift 6. If we do it, it would have to be for a later language mode, and the source compatibility impact will be the major point of debate.

2 Likes
23

You can definitely have a language that consistently auto-initialises uninitialised variables to some default value, like so:

protocol DefaultInitializable {
    static var defaultValue: Self { get }
}
extension Int: DefaultInitializable {
    static let defaultValue = 0
}
extension Bool: DefaultInitializable {
    static let defaultValue = false
}
// and so on

// usage:

struct Foo {}

struct Bar: DefaultInitializable {
    static let defaultValue = Bar()
}

var x: Int
print(x) // ✅ 0
var foo: Foo
print(foo) // 🛑 Error, not initialized
var bar: Bar
print(bar) // ✅

I just don't think this could be ever in Swift.

24

With non-copyable support, do we have mechanisms powerful enough to track the ownership of globally shared variables now? It occurs to me that this is perhaps the most difficult part for implementation.

With concurrency and ownership guarantees we can improve the safety of global variables, and greatly narrow the gap between global and local variables.

25

How are optionals different from other variables in this respect?

26

Thank you for the unofficial insight. At least it’s nice to know that it’s not impossible that the change would be made in Swift 7.

1 Like
27

If the change is agreed in principle to be implemented in some future Swift version and just the time frame is not certain we could issue the relevant warning:

struct S {
    var field: Int?
}
S() // 🔶 Warning: will be an error in future (suggestion...)
var x: Int?
print(x) // 🔶 Warning: will be an error in future (suggestion...)

With no fix-it / migration to keep the change implementation simple for now.

3 Likes