[swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

Chris Lattner clattner at nondot.org
Sun Jul 23 17:57:00 CDT 2017

On Jul 22, 2017, at 3:03 PM, Daryle Walker <darylew at mac.com> wrote:
>> In my opinion, there is an easy three step plan :-) to solving this problem, riffing on Array:
> Well, fixed-size arrays don’t have initializers, for the same reason tuples don’t: they’re compound types instead of named types and they literally have nowhere to place initializer definitions. But like tuples, FSAs have a literal syntax that works as a substitute for full-blown initializers.

Ok, sure.  They aren’t literally initializers in the stdlib (they are built into the compiler), but they have initialization semantics and can be spelled in whatever way makes ergonomic sense.  Keeping them aligned with Array seems like a good starting point.

>> IMO, it isn’t a problem that C allows arrays to be uninitialized - the problem is that it is a really bad default.
> I was struggling which way to go; add run-time deterministic initialization or allow undefined behavior. For now, it’s neither; the current compile-time deterministic initialization has to be followed. But compile-time DI isn’t big a setback as long as you have all the information you need to set every element before initialization-assignment (with a function term).

If you’re thinking of allowing something like:

var x : Int[4]   // or whatever

// These are all initializations
x[0] = 1
x[1] = 2
x[2] = 3
x[3] = 4

Then it is possible to enable some simple cases (like this), but not the more useful and general cases.  I’d suggest starting without this, since it could be added at any time in the future if there were a compelling reason to.


More information about the swift-evolution mailing list