> On Jul 13, 2017, at 1:28 PM, Robert Widmann <[email protected]> wrote: > >> On Jul 12, 2017, at 9:09 PM, Daryle Walker <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Jul 12, 2017, at 4:05 PM, Robert Widmann <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I think this proposal is trying to do too much at once. Correct me if I’m >>> wrong, but you’re proposing >>> >>> 1) New sugar for fixed-length arrays without a corresponding stdlib >>> declaration >> >> IIUC, “sugar” means an easier way to use existing functionality, right? In >> this proposal, there is neither sugar nor a standard library declaration for >> the same reason: these arrays are a new primitive at the user and ABI >> levels, not a library type. What is the (existing since you mentioned sugar) >> primitive you’re expecting a library fixed-size array to be based on? > > “Sugar” means an equivalent way to spell something concrete, but here there > is nothing concrete. We’d be hard-coding a magical library type into the > compiler which is something that, up to now, we have refrained from doing > because it massively complicates type checking and forces us to compromise to > work around “just this one corner case”. Our notion of a “primitive” is not > the same as C and C++; Int, Float, String, these are all Standard Library > types - that happen to be backed by compiler intrinsics in some cases.
I don’t mean fixed-size arrays are a type vs. Int / Float / String (i.e. primitive types), but a kind of type vs. class / struct / enum / tuple (i.e. type primitives). It’s a primitive because it cannot be implemented by existing features. It's why the proposal mentions bit-code representations and ABI changes instead of library ones (besides support). >> >> Obviously, this means arrays can’t be implemented until at least Swift 5. >> >>> 2) Arity and type inference for literals >> >> I don’t know what you mean by these. > > > var b: [_, _] = [3.14159, 2.71828] > > On the syntactic side: underbar has a very specific meaning in this language, > and “infer this type/arity” isn’t one of them. I guessed this after I woke up this morning. A way around this would be a new (but similar) kind of literal. But we’ve already used up all the ASCII bracketing character pairs. And you see there’s problems reusing the square brackets that array- and dictionary-literals use. Maybe we can chord the square brackets with something else: #[1, 2, 3, 4]# // [4: Int] #[6; 1, 2, 3, 4]# // [6: Int], last two elements to be initialized later #[6; “a", “b", “c", “d", default: “k"]# // [6: String], all elements initialized, need semicolon since the comma and colon are already used #[6; 0: “a", 2: “c", 1: “b", 3: “d", default: “k"]# // [6: String], with specific indexes assigned per element initializer #[2, 2; #[0, 0]#: 1, #[0, 1]#: 2, #[1, 0#]: 3, #[1, 1]#: 4]# // [2, 2: Int], this form gets long really fast, maybe use the closure version #[1, 2, 3, 4]# as [2, 2: Int] // Reshaping uses less text #[0;]# // Empty array #[]# // Also empty array, can be used a shortcut initializer for any FSA to indicate no elements initially initialized >> >>> 3) Default initialization semantics for arrays including a DI exception for >>> fixed-length arrays that aren’t fully initialized >> >> My first thought was full initialization, like other objects, but someone on >> the list really wanted a way to not have full initialization. I could see >> his point; filling in a bunch of zeros for a large array for math purposes >> could get expensive, especially if the values are immediately ran over. Even >> if we make closure-initialization return non-optionals, we still have to >> worry when an array is filled by a loop that gets exited early. > > As long as you have this magical type, you should probably give it some > magical methods. A “backfill” initializer, perhaps. We cannot break DI just > because it’s syntactically inconvenient. > There’s already the “default” term in extended array literals. And the “func” term allows the elements to be determined via closure. For DI, it’s worse than you think, which is why I put out a separate post on this issue. DI assumes one sub-declaration per sub-object; the raison de-tere for arrays is to defeat this assumption. DI and FSAs are fundamentally incompatible; something has to break (forced initialization on declaration, static array indexing, run-time DI, or undefined behavior on possible uninitialized reads). > You’ve also stumbled onto the notion of a “reasonable default”, which for a > language with a rich type system is a farce. We can’t assume every type has > some reasonable default that we can fill in automatically because many types > don’t (for an extreme example, see Never). > >> >>> 4) 2 new attribute declarations for unspecified concurrency semantics >> >> Why not add some modern features relative to classic C? Or is it possible >> for these to be automatically determined (and carried out) by the compiler? >> I don’t think the vector-unit one can. > > You must define these semantics. We cannot hand-wave about something so > massively complicated. For one, I don’t know what “automatically determined” > in regards to a non-referentially-transparent language means. I meant could the compiler see the code in the loop, determine there’s no cross-iteration dependencies (or other disqualifiers) and apply the effects of the “parallel” attribute automatically. I’m not a professional compiler writer, so I don’t know how much I have to specify and how much I can punt to the Swift developers to figure it out. If I have to do more on my side, I would appreciate help from actual compiler writers on what to put down. >> >>> 5) A magical compiler intrinsic that declares loop counters >> >> Having the compiler figure out the best way to iterate an array seems a lot >> better than manually doing a bunch of loop and range calls, especially for >> multi-dimensional arrays. (I want one loop statement, no matter the number >> of dimensions.) But without those manual calls, you need some other way to >> determine your position in the loop. >> > > See above. Auto-vectorization semantics are great, but we have to have them > defined first. > >>> 6) Static collection subtyping constraints referencing convertibility >>> constraints we don’t currently have >> >> I copied that from the section of the ABI document about tuples. We could >> drop it. >> >>> 7) Tuple conversions >> >> Since these arrays will replace manually homogenous tuples as the conversion >> for C arrays, we need a way to handle older code. I probably wouldn’t have >> bothered except for backwards compatibility. > > We control the import of those “tuples", so we could switch them to be > imported as your new type. If you can make your proposal function in a > backwards-compatible manner we wouldn’t need this. New imports would use FSAs, but it wouldn’t be retroactive, so there needs to be a conversion between old C-array adaptations and the new ones. Unless you mean for translated C code to interact with newer Swift code, the C code would have to be re-adapted (which would swap out manually homogenous tuples for FSAs in the new source files)? >> >> Are manually homogenous tuples, with the multiplicity of the element type is >> specified with lexical repetition instead of a number, the sugar from point >> 1? If so, that use would be depreciated, not continued. >> >>> I believe your aims are noble, and this is certainly a tremendously >>> important problem we need to solve, but I think there needs to be a >>> measured response to the current state of things. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
