There are other alternatives that don't use generics. Last time this came around, the straw man syntax was (4 x Int), and it was merely to be a shorthand for (Int, Int, Int, Int).
Every non-existing feature that needs to be implemented to make fixed-size arrays work are a drag. I've said it before and I'll say it again: major features that this proposal wants to rely on should be brought independently and discussed on their own. There are real problems with monolithic proposals: They couple independent features in an all-or-nothing basket They consume a huge amount of review and design energy They force sub-features to be viewed through the telescope aimed at the main feature, and make it easier to miss problems or opportunities in the big pictures The last point is especially worrying to me because things like non-type generic parameters are *much bigger* than fixed-size arrays. I think that it's a priority inversion to discuss non-type generic parameters as a bullet point of fixed-size arrays. Félix > Le 24 juil. 2017 à 01:37, David Sweeris <daveswee...@mac.com> a écrit : > > Which brings us I think full circle back to using literal values as generic > parameters, "let fsa = FSA<Type, Count>(whateverArgs) //where `Count` is an > integer literal, or some other integer value that can be determined at > compile time". > > - Dave Sweeris > > On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> It is not good enough for C interop because a design where the element count >> is data rather than part of the type cannot be layout-compatible with a C >> fixed-size array. >> >> Félix >> >>> Le 23 juil. 2017 à 22:22, Charles Srstka via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >>> >>> 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) >>> >>> Charles >>> >>>> On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> This proposal gives FSAs their own literal syntax. You write [; 3, 5] to >>>> make a FSA, not [3, 5]. >>>> >>>> On Sun, Jul 23, 2017 at 11:54 PM, David Sweeris <daveswee...@mac.com >>>> <mailto:daveswee...@mac.com>> wrote: >>>> >>>> On Jul 23, 2017, at 8:32 PM, Taylor Swift <kelvin1...@gmail.com >>>> <mailto:kelvin1...@gmail.com>> wrote: >>>> >>>>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris <daveswee...@mac.com >>>>> <mailto:daveswee...@mac.com>> wrote: >>>>> >>>>> On Jul 23, 2017, at 12:18, Taylor Swift <kelvin1...@gmail.com >>>>> <mailto:kelvin1...@gmail.com>> wrote: >>>>> >>>>>> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris <daveswee...@mac.com >>>>>> <mailto:daveswee...@mac.com>> wrote: >>>>>> >>>>>> On Jul 23, 2017, at 09:08, Taylor Swift <kelvin1...@gmail.com >>>>>> <mailto:kelvin1...@gmail.com>> wrote: >>>>>> >>>>>>> let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ??? >>>>>> >>>>>> Correct. If you wanted a multidimensional array, that'd be written "let >>>>>> nestedFSA: [2*[5*Int]]". Or, speculating a bit, I suppose maybe "let >>>>>> nestedFSA: [[5*Int]*2]", if we wanted there to be a column-major option. >>>>>> IMHO all those read better than this proposal's syntax. >>>>>> >>>>>> >>>>>> >>>>>> No, what I’m saying is does the phrase “[2 * 5, 3]” mean a fixed size >>>>>> array of length two and with the elements 5 and 3, or a flexible sized >>>>>> array with two elements 10 and 3? This is v confusing and difficult to >>>>>> read, especially when you have actual multiplications going on such as >>>>>> >>>>>> let fsa:[2 * Int] = [2 * 3 * 5, 3] // [15, 3] ??? >>>>> >>>>> That's... huh? To me, "[2 * 3 * 5, 3]" should obviously evaluate to "[30, >>>>> 3]". How are you getting that "[2*5*3, 3]" could be a 2-element FSA >>>>> containing 15 and 3? Are you suggesting that instead of "[value * value * >>>>> value, value]", it could be parsed as "[modifier value * value, value]" >>>>> (with `modifier` being "2 *")? To me, that syntax would strongly suggest >>>>> that the modifier only applies to the first element of the array, which >>>>> would mean the only other option for parsing it would be equivalent to >>>>> "[[3, 5], 3]", which is neither a match for fsa's type, nor a >>>>> semantically valid array (the elements have to be the same type), nor a >>>>> syntactically valid array (the nested array in the first element is >>>>> missing its "[]"). >>>>> >>>>> >>>>> Well, that is the syntax you’re proposing right? What comes on the left >>>>> of the asterisk is the FSA dimensions, and what comes to the right is the >>>>> FSA elements. >>>> >>>> No, the type of the FSA's elements is what comes to the right: "[count * >>>> Type]". I don't recall any discussion around the value side of things, so >>>> I'd guess they would've just used the existing array literal syntax, "let >>>> fsa: [2*[2*Int]] = [[0, 1], [2, 3]]". >>>> >>>> - Dave Sweeris >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
