> On Jul 12, 2017, at 9:09 PM, Daryle Walker <[email protected]> wrote: > > >> On Jul 12, 2017, at 4:05 PM, Robert Widmann <[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. > > 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. > >> 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. 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. > >> 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. > > 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
