As I understand it, Definitive Initialization means the Swift compiler will make sure an instance is fully initialized before the first attempt to read it. It does not require mandatory assignment at declaration; an instance can be declared with no initializer and receive an assignment at a later point.
* Class and structure types are considered OK by DI when an initializer is called. * Enumerations can either use an initializer or have an enumeration-case assigned for DI. * Compound types (function pointers and tuples) use assignment (possibly at declaration) for DI. * Tuples can also have the individual members can be tracked for DI. A member has to be initialized by the time that member or the entire tuple is read (whichever comes first). Tuples (and the other types) can statically determine when a sub-object is initialized. When adding a new member, via new text in the source code, a corresponding new line(s) of code has to be added during the initialization sequence. But built-in arrays, no matter how they’re defined, would be different. The whole point of arrays is to allow adjustment the number of sub-objects without per-sub-object alteration to the array type’s declaration code. That means you can’t write out all the member initializations in advance (in general). And that means you generally use a loop and subscripting instead. And since that moves the references to which elements get initialized to run-time, we have a fundamental incompatibility with definitive initialization. (The fixed-size array proposal I recently posted about does have a static indexing mode, but the point I’m making here is that it doesn’t scale from the perspective of the regular array interaction model.) Besides banning fixed-size arrays forever and ever (which just hides the problem), we’re limited to: * Mandatory assignment at declaration, and the initializing expression has to cover all elements * If arrays keep a static indexing mode, apply DI to an array instance using that. This would mean changing the initialization sequence code every time the number of elements is adjusted. And the initialization would have to be from the static indexing mode for DI to recognize it (i.e. always “a.0 = 4”, no “a[0] = 4”) Note that if we gain an equivalent to C++’s constexpr, then static indexing mode could be spelled with the subscript operation. * For each array instance not initialized on declaration, define a secret extra Boolean-array object that keeps the initialization state of each element of the first array. Of course, this means tracking each element read and raising a run-time error if not initialized first. * Something I haven’t considered. If anyone from the original Swift team is around: is this why you didn’t add fixed-size arrays at the start? (Or did you just forget?) I don’t think you missed a way to link FSAs to DI; the two are just incompatible (if you want to keep the way most people use arrays). So I’m asking for either some way to make FSAs and DI work together that I missed. Or start a discussion on how undefined behavior on uninitialized-data reads should work on compiler, ABI, and run-time levels. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
