> On Jul 24, 2017, at 1:22 AM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > Do FSAs really need special sugar, though? They won’t be an extremely > heavily-used construct, but rather they’ll be occasionally used either for > performance reasons or to interact with C APIs. Sure, C had a short syntax > for making them, but making pointers in C was short, too, and that hasn’t > been carried over into Swift. In fact, a FSA has a lot in common with an > UnsafeBufferPointer that you don’t have to worry about deallocating. > Furthermore, there are collection types such as Set and ContiguousArray which > are arguably more useful than FSA, yet don’t have their own syntax. > > Is this really not good enough? > > let arr = FixedArray<Type>(capacity: x)
Yes, it’s not good enough. This looks like it would be a struct in the standard library. And named types have at least one initializer, and one of which must be called during non-assignment initializations. But named types must be completely initialized by the time any initializer ends, and that’s a non-goal for FSAs. My FSA design uses compound types so we can initialize in piecemeal. (We could suspend complete initialization for these static named array types, but that inconsistency would be a “cure worse than the disease” solution.) Also, this looks like the array bounds are determined at run-time, requiring remote storage, which is an anti-goal. One of the main goals of FSAs is to use scoped storage (unlike Array) with easy indexing (unlike tuples). Newer versions of C have a function to dynamically use scoped storage, so we could use that, but we usually know what array shape we need at compile-time, so why move the decision to run-time? And dynamically determined scoped storage would screw up use as sub-objects. If it’s not a named type, but a compound type with named-type-looking syntax, it’s too much of an anti-sugar solution. — 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
