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> 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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
