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

> We don’t want to add conformance then find out that was a mistake. I think we also don't want to create restrictions based on future additions that might never happen... > Besides that they can’t be Sequences, unless you throw away allowing > parallel/vector processing in the future. (That

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

> On Aug 3, 2017, at 7:20 AM, Tino Heth <2...@gmx.de> wrote: > > Hi Daryle, > > I think we agree a lot on the importance of fixed-size arrays, but have a > different opinion on which aspect is the most valuable… (so we now only have > to agree that mine is better ;-) ;-) > My motivation for

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

> I’m not saying that tuple member names are “true integers” (although, with > Reflection…). I understood that, semantically, the reason we refer to > elements .0, .1 and .2 of a tuple because that’s their name, not necessarily > because its their position in the tuple. My point is that for a

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

> On 3. Aug 2017, at 07:26, John McCall wrote: > >> On Aug 3, 2017, at 12:45 AM, Daryle Walker > > wrote: >>> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >>>

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

> Honestly, a lot of this still applies. I would like to see fixed-sized > arrays in the language eventually, but they are not going to become a > priority, because there's a lot of other stuff that is more important to work > on. I guess it all depends on the the future focus of the

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

Hi Daryle, I think we agree a lot on the importance of fixed-size arrays, but have a different opinion on which aspect is the most valuable… (so we now only have to agree that mine is better ;-) ;-) My motivation for FSA is safety and convenience: I want to iterate over C arrays in a

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

> On Aug 3, 2017, at 12:45 AM, Daryle Walker wrote: >> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >> > wrote: >> >> I’m -1 on adding a fixed-sized Array type. >> >> It goes back to something which I

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

> On Aug 2, 2017, at 21:45, Daryle Walker via swift-evolution > wrote: > > I’m not good at explicit explanations, so having to justify adding a type > that’s been around for a long time (at least FORTRAN 4+ decades ago) an > almost every systems programming

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

FSA indices may be nominal, but you still need some way to store them. A good example of this is when you’re implementing cubemaps with 3-tuple vectors. Selecting a cube face involves selecting components of the vector at a variable offset supplied by a function parameter. Doing this with a switch

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

> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution > wrote: > > I’m -1 on adding a fixed-sized Array type. > > It goes back to something which I remember reading from John McCall earlier > this week but can’t find any more: about tuple indices being

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

> On Aug 1, 2017, at 7:21 PM, John McCall wrote: > >> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution >> wrote: >>> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution >>> wrote: >>> >>> A

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

I’m -1 on adding a fixed-sized Array type. It goes back to something which I remember reading from John McCall earlier this week but can’t find any more: about tuple indices being nominal and not ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal? The difference

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

> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution > wrote: >> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution >> wrote: >> >> A tuple can have its members initialized in piecemeal and still satisfy >>

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

> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution > wrote: > > A tuple can have its members initialized in piecemeal and still satisfy > deterministic initialization. The named types need to do all their > sub-objects' initializations before any

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

>> What exactly is the problem with Sequence that makes you believe there is >> need for a more basic protocol? > > For one, the return value of map is wrong. Sequence.map returns an Array, > since a Sequence may not be a container itself. Using Array may be a minor > inconvenience for

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

> On Aug 1, 2017, at 1:03 PM, Tino Heth <2...@gmx.de> wrote: > >> Sequence/Collection have other problems fitting with fixed-size arrays. >> There needs to be a new set of more basic protocols that both arrays and >> Sequence or Collection can conform to. > What exactly is the problem with

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

> On Aug 1, 2017, at 10:03 AM, Tino Heth via swift-evolution > wrote: > >> But linear access isn’t an inherent canonical property of multi-dimensional >> arrays, it’s just a consequence of arrays taking a contiguous block of >> memory (which is generally treated

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

> But linear access isn’t an inherent canonical property of multi-dimensional > arrays, it’s just a consequence of arrays taking a contiguous block of memory > (which is generally treated as linear in computers). Do you know about any attempts to change this? I've seen setups of two-dimensional

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

> On Aug 1, 2017, at 3:21 AM, Tino Heth <2...@gmx.de> wrote: > >> FSAs intentionally don’t conform to Collection, because multi-dimensional >> arrays shouldn’t have to conform to a linear (by nature, hence the name >> “Sequence”) standard, at least by default. > I strongly oppose and think it

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

> FSAs intentionally don’t conform to Collection, because multi-dimensional > arrays shouldn’t have to conform to a linear (by nature, hence the name > “Sequence”) standard, at least by default. I strongly oppose and think it is a really bad idea: Even if arrays are modelled multi-dimensional,

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

> On Jul 30, 2017, at 4:54 PM, Félix Cloutier wrote: > >> Le 29 juil. 2017 à 16:01, Daryle Walker a écrit : >> >>> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution >>> wrote: >>> >>> It seems to me that I'm the

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

> Le 29 juil. 2017 à 16:01, Daryle Walker a écrit : > > >> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution >> wrote: >> >> It seems to me that I'm the one advocating for fewer language changes, and >> the majority of sub-features

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

> And other people complained about that! If I learned anything from Swift evolution, than it is that there are terrifying differences in the perception of things ;-) — Some want to get rid of object orientation, others are fond of it — Some want to enforce that "self." has always to be written

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

> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution > wrote: > > It seems to me that I'm the one advocating for fewer language changes, and > the majority of sub-features that are being requested here don't feel > particularly more general to me. > >

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

> On Jul 24, 2017, at 7:29 AM, Tino Heth <2...@gmx.de> wrote: > > 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

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

> On Jul 23, 2017, at 11:20 PM, Taylor Swift wrote: > > On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker > wrote: > >> On Jul 23, 2017, at 12:04 PM, Taylor Swift > > wrote: >

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

> On Jul 24, 2017, at 1:22 AM, Charles Srstka via swift-evolution > wrote: > > 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

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

> Le 24 juil. 2017 à 10:43, Tino Heth <2...@gmx.de> a écrit : > > >> 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? This is a bit of a naive thing to say since we

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

> 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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

> Allowing partial indexing as you show it privileges one dimension over the > others, although they’re supposed to be co-equal and the reason a particular > dimension is privileged is due to an implementation detail. Isn’t this a pretty important implementation detail? One of the reasons for

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

> 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

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

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

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

Between comma, semicolon, and colon, I think semicolon is the best choice (though I would prefer double colon over all three). However I don’t think we should discard possible alternatives just because they aren’t already reserved separators. Neither ',', ';', ':', nor '::' is particularly

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

> On Jul 23, 2017, at 3:18 PM, Taylor Swift via swift-evolution > wrote: > > > If we’re actually going to try and establish a relationship between the FSA > asterisk and the multiplication asterisk, this is even more problematic. How > does the asterisk work in

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

> On Jul 23, 2017, at 12:04 PM, Taylor Swift wrote: > > > > On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker > wrote: > >> 9. I don’t see the value in having both nested FSAs and multi-dimensional >> FSAs. Aren’t they the same

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

> On Jul 23, 2017, at 2:07 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > I think fixed-size arrays should be a nominal type like any other. They > should be able to have methods, conform to protocols, be extended with new > behavior, and generally

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

> On Jul 23, 2017, at 5:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift > wrote: > >> I don’t think tuples are a suitable replacement for FSAs. A tuple should be

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

On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker wrote: > > > > On Jul 23, 2017, at 12:04 PM, Taylor Swift wrote: > > > > On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker wrote: > >> >> 9. I don’t see the value in having both nested FSAs and

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

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift > wrote: > >> Speaking of which, IIRC, at one point we were considering adding subscripts

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

> On Jul 23, 2017, at 2:49 PM, David Sweeris via swift-evolution > wrote: > > > On Jul 23, 2017, at 12:18, Taylor Swift > wrote: > >> On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris >

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

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

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

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:

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

> 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

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

I think fixed-size arrays should be a nominal type like any other. They should be able to have methods, conform to protocols, be extended with new behavior, and generally present a user-experience similar to what arrays already have. In particular, they should conform to Collection and to

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

Well even if the behavioral subtyping might not fit for hundred percent in this scenario, my main point is that I don’t want Swift to contain exclusive features. By that I mean that it’s far better to come up with something that has more potential and where the syntax could be reused for other

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

I’ll throw my syntax suggestion into the mix: backslashed brackets for the braces, a colon for the separator. let fsa: \[3: Int\] = \[3: 1, 2, 3\] Or maybe go the string interpolation route and only backslash the first bracket. let fsa: \[3: Int] = \[3: 1, 2, 3] I think that looks pretty

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

lol we might as well use a lozenge as the separator let fsa:[3, 2 <> Int] = [3, 2 <> 1, 2, 3, 4, 5, 6] Some languages like Pollen even go the unicode route and use an actual lozenge let fsa:[3, 2 ◊ Int] = [3, 2 ◊ 1, 2, 3, 4, 5, 6] this character is actually very easy to type (≤ 3 keystrokes)

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

On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker wrote: > > 9. I don’t see the value in having both nested FSAs and multi-dimensional > FSAs. Aren’t they the same thing? For example, in the code snippet > > > Why does any language with multi-dimensional arrays (like Fortran or

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

Sent from my iPhone > On Jul 23, 2017, at 08:45, Taylor Swift via swift-evolution > wrote: > > > >> On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution >> wrote: >> I wanted to read the proposal, but skipped it as soon

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

On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > I wanted to read the proposal, but skipped it as soon as I’ve seen the > syntax. From the esthetic point of you the proposed syntax is really ugly. > Again I’m not speaking against the

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

I wanted to read the proposal, but skipped it as soon as I’ve seen the syntax. From the esthetic point of you the proposed syntax is really ugly. Again I’m not speaking against the feature in general, nor against any of the technical benefits fixed-size array will provide to us. I simply

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

> On Jul 22, 2017, at 9:14 PM, Taylor Swift wrote: > > Hi, I’ve been watching this proposal for a while but didn’t get to read it in > detail until now. I really like this idea and it’s very comprehensive and > well-thought out. Some feedback: > > 1. I got very confused

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

Hi, I’ve been watching this proposal for a while but didn’t get to read it in detail until now. I really like this idea and it’s very comprehensive and well-thought out. Some feedback: 1. I got very confused reading through the document the first time through. You’re introducing a huge amount of

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

It’s at >. * Try to clarify that fixed-size arrays are a new kind of compound type, not a (ridiculously magical) library generic type. * Change the separator