Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth via swift-evolution]

> The last point is especially worrying to me because things like non-type 
> generic parameters are *much bigger* than fixed-size arrays.

Why do you think that's the case?

And even if it's really more challenging than FSAs:
Would that be enough justification to add a bunch of language changes right 
now, ignoring more general concepts which offer a good syntax for them without 
extra cost?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[David Sweeris via swift-evolution]

> On Jul 24, 2017, at 9:37 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 23, 2017, at 4:27 PM, Félix Cloutier  wrote:
>> 
 
 Well, fixed-size arrays don’t have initializers, for the same reason 
 tuples don’t: they’re compound types instead of named types and they 
 literally have nowhere to place initializer definitions. But like tuples, 
 FSAs have a literal syntax that works as a substitute for full-blown 
 initializers.
>>> 
>>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built 
>>> into the compiler), but they have initialization semantics and can be 
>>> spelled in whatever way makes ergonomic sense.  Keeping them aligned with 
>>> Array seems like a good starting point.
>> 
>> Either way, in the context of fixed-size arrays, I think that it's a broader 
>> problem that anonymous types can't have anything attached to them. This also 
>> prevents fixed-size arrays from conforming to protocols, even Sequence, and 
>> Swift would need variadic generics or (possibly, depending on the syntax) 
>> non-type generic parameters to even create a wrapper.
> 
> Agreed. However, solving that general problem is hard, and completely 
> orthogonal to the win of having fixed sized arrays work.

Is there really any doubt that we'll eventually get Variadic Generics and 
Non-Type Generic Parameters? They're always well-received whenever they come 
up, but they keep getting ruled out-of-scope before a proposal can be fully 
fleshed-out. I'm asking because it'd make it way easier to design a FSA 
proposal knowing that it could rely on those features. Personally, I'd even be 
ok with accepting such a proposal "pending the acceptance of its 'dependency 
proposals'" (with probably a quick re-review to make sure any subsequent 
proposals haven't materially changed how it'd work).

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

> On Jul 24, 2017, at 9:22 AM, Félix Cloutier  wrote:
> 
> 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.

+ all the 1s

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Chris Lattner via swift-evolution]

> On Jul 23, 2017, at 4:27 PM, Félix Cloutier  wrote:
> 
>>> 
>>> Well, fixed-size arrays don’t have initializers, for the same reason tuples 
>>> don’t: they’re compound types instead of named types and they literally 
>>> have nowhere to place initializer definitions. But like tuples, FSAs have a 
>>> literal syntax that works as a substitute for full-blown initializers.
>> 
>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built 
>> into the compiler), but they have initialization semantics and can be 
>> spelled in whatever way makes ergonomic sense.  Keeping them aligned with 
>> Array seems like a good starting point.
> 
> Either way, in the context of fixed-size arrays, I think that it's a broader 
> problem that anonymous types can't have anything attached to them. This also 
> prevents fixed-size arrays from conforming to protocols, even Sequence, and 
> Swift would need variadic generics or (possibly, depending on the syntax) 
> non-type generic parameters to even create a wrapper.

Agreed. However, solving that general problem is hard, and completely 
orthogonal to the win of having fixed sized arrays work.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Félix Cloutier via swift-evolution]

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  a écrit :
> 
> Which brings us I think full circle back to using literal values as generic 
> parameters, "let fsa = FSA(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 
> > 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 
>>> > 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(capacity: x)
>>> 
>>> Charles
>>> 
 On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution 
 > 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 > wrote:
 
 On Jul 23, 2017, at 8:32 PM, Taylor Swift > wrote:
 
> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris  > wrote:
> 
> On Jul 23, 2017, at 12:18, Taylor Swift  > wrote:
> 
>> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris > > wrote:
>> 
>> On Jul 23, 2017, at 09:08, Taylor Swift > > 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 
> 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth via swift-evolution]

> I simply dislike the syntax, which in my opinion does not fit to Swift.
+1

Also, I might have a different focus for the feature:
Performance and C interoperability are important, but I just want type safety 
and to avoid creating stupid things like Vector3, Vector4… which can't share 
code because there's no inheritance for structs (yet), and which are limited in 
expressiveness.

I don't think arrays should be multidimensional: Memory has only one dimension, 
this is a low level feature — and it's easy to build multi-dimensional 
structures on top of simple arrays.

I also have little need for a special syntax for literals: When the array is 
used as communication medium ("this function returns an array of size 3"), I'm 
not using literals at all, and when I'm declaring a array for my own use, I 
wouldn't mind if the compiler decides on his own that it can be fixed size.
There's also the use case of creating an array that will be handed over to a 
method that expects a FSA, but I wouldn't mind if I have to declare the type 
explicitly in this case.

Bottom line:
I prefer only one addition, and that is an extension of the generics system 
that has already been brought up in the manifesto.
With generics, the syntax for arrays is quite intuitive ("let speed: 
Array"), and the usefulness isn't limited to FSAs alone — after 
all, Swift  is used in production for several years now without proper support 
for them.

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[David Sweeris via swift-evolution]

Which brings us I think full circle back to using literal values as generic 
parameters, "let fsa = FSA(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 
>  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 
>>  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(capacity: x)
>> 
>> Charles
>> 
>>> On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution 
>>>  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  
 wrote:
 
> On Jul 23, 2017, at 8:32 PM, Taylor Swift  wrote:
> 
>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris  
>> wrote:
>> 
>>> On Jul 23, 2017, at 12:18, Taylor Swift  wrote:
>>> 
 On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris  
 wrote:
 
> On Jul 23, 2017, at 09:08, Taylor Swift  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
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Félix Cloutier via swift-evolution]

The mere virtue of a strong typealias won't provide an implementation of the 
Sequence protocol, and as was just established, the language isn't equipped to 
provide an automatic implementation through the standard library. Your 
suggestion is an entry point for compiler magic. If we get into that territory, 
I would much rather have compiler magic that doesn't require me to find a 
human-readable name for an array type just for the privilege of iterating over 
its values, and that doesn't make identical array types incompatible with one 
another.

Félix

> Le 23 juil. 2017 à 20:05, Daryle Walker  a écrit :
> 
>> 
>> On Jul 23, 2017, at 7:27 PM, Félix Cloutier  wrote:
>> 
>> I think I've already said that, but I agree that an incremental approach to 
>> this would be better.
>> 
>>> Le 23 juil. 2017 à 15:57, Chris Lattner  a écrit :
>>> 
>>> On Jul 22, 2017, at 3:03 PM, Daryle Walker  wrote:
> In my opinion, there is an easy three step plan :-) to solving this 
> problem, riffing on Array:
 
 Well, fixed-size arrays don’t have initializers, for the same reason 
 tuples don’t: they’re compound types instead of named types and they 
 literally have nowhere to place initializer definitions. But like tuples, 
 FSAs have a literal syntax that works as a substitute for full-blown 
 initializers.
>>> 
>>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built 
>>> into the compiler), but they have initialization semantics and can be 
>>> spelled in whatever way makes ergonomic sense.  Keeping them aligned with 
>>> Array seems like a good starting point.
>> 
>> Either way, in the context of fixed-size arrays, I think that it's a broader 
>> problem that anonymous types can't have anything attached to them. This also 
>> prevents fixed-size arrays from conforming to protocols, even Sequence, and 
>> Swift would need variadic generics or (possibly, depending on the syntax) 
>> non-type generic parameters to even create a wrapper.
> 
> My solution to tuples and fixed-size arrays not supporting attached 
> interfaces is to make a strong type-alias to the compound type and add your 
> interface there. And unlike alternatives added to the core language level, 
> users who don’t want that particular extended interface (or want an 
> incompatible one!) don’t have to live with it. It’s part of the “alternative 
> types” proposal.
> 
> — 
> 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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Félix Cloutier via swift-evolution]

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 
>  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(capacity: x)
> 
> Charles
> 
>> On Jul 23, 2017, at 11:03 PM, Taylor Swift via swift-evolution 
>> > 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 > > wrote:
>> 
>> On Jul 23, 2017, at 8:32 PM, Taylor Swift > > wrote:
>> 
>>> On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris >> > wrote:
>>> 
>>> On Jul 23, 2017, at 12:18, Taylor Swift >> > wrote:
>>> 
 On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris > wrote:
 
 On Jul 23, 2017, at 09:08, Taylor Swift > 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 
>> 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