Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution > wrote: > > Static-sized arrays should not be shoved into being a tuple with funny > settings; that introduces subtleties into the tuple concept only because of > jammed-in array support. The fact 3

Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 2, 2017, at 10:26 AM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jun 02 2017, Brent Royal-Gordon > wrote: > >>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >>>

Re: [swift-evolution] Yet another fixed-size array spitball session

> On Jun 2, 2017, at 2:20 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >> > wrote: >> >> Static-Sized Arrays > > My preference

Re: [swift-evolution] Yet another fixed-size array spitball session

on Fri Jun 02 2017, Brent Royal-Gordon wrote: >> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >> wrote: >> >> Static-Sized Arrays > > My preference would still be to build this from four separate features: > > 1. Magic

Re: [swift-evolution] Yet another fixed-size array spitball session

Sent from my iPad > On Jun 2, 2017, at 7:33 AM, Xiaodi Wu via swift-evolution > wrote: > > > On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution > wrote: >>> On May 28, 2017, at 11:37 PM, Daryle Walker via

Re: [swift-evolution] Yet another fixed-size array spitball session

On Fri, Jun 2, 2017 at 04:28 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution < > swift-evolution@swift.org> wrote: > > Static-Sized Arrays > > My preference would still be to build this from four separate

Re: [swift-evolution] Yet another fixed-size array spitball session

> On 2 Jun 2017, at 07:38, Robert Bennett wrote: > > My favorite proposal so far is one that was posted a while ago, [Int * 4]. I > think that this syntax looks pretty Swifty. There isn't an oddball subscript > operator like with Int[4], and there isn't a need to allow

Re: [swift-evolution] Yet another fixed-size array spitball session

> 1. Magic tuple conformances: We already want to be able to automatically > conform tuples to protocols like Equatable, Hashable, and Comparable. These > can all be compiler magic; they don't have to be definable in userspace. > > 2. Conform tuples to Collection: The Element type should be the

Re: [swift-evolution] Yet another fixed-size array spitball session

Just a small question, named tuples => Dictionary? Or how would that resolve? > On Jun 2, 2017, at 2:20 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >>

Re: [swift-evolution] Yet another fixed-size array spitball session

New Spitball But first: C has one of the worst array presentation models. It has traumatized so many that those among them that grew up to be language designers themselves threw out fixed-sized arrays entirely (from Java to even current Swift!). But we’re getting through to everyone that the

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution > wrote: > > Static-Sized Arrays My preference would still be to build this from four separate features: 1. Magic tuple conformances: We already want to be able to automatically conform tuples to

Re: [swift-evolution] Yet another fixed-size array spitball session

My favorite proposal so far is one that was posted a while ago, [Int * 4]. I think that this syntax looks pretty Swifty. There isn't an oddball subscript operator like with Int[4], and there isn't a need to allow generics to support values as parameters. It's clear that [Int * 4] will be

Re: [swift-evolution] Yet another fixed-size array spitball session

Just wanted to add my two-cents to this discussion, but in terms of syntax I think that the basic method for specifying size should be with some kind of type variables, like so: struct MyFixedArray { … } The idea being that we can then use size as a variable anywhere

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 31, 2017, at 10:38 AM, Tino Heth via swift-evolution > wrote: > > I don't want to write things like "Vector3D" and "Vector4D" to wrap a static > array just to ensure that it has the right size, and I don't want to have > runtime-checks which would decrease

Re: [swift-evolution] Yet another fixed-size array spitball session

If you replace “heap access” with “heap allocation/deallocation” in the argument, then the performance differences become very relevant. > On May 31, 2017, at 10:15 AM, David Waite via swift-evolution > wrote: > > >> On May 31, 2017, at 9:28 AM, Robert Bennett via

Re: [swift-evolution] Yet another fixed-size array spitball session

> My suggestion: have two constructors, StaticArray(size: LiteralInteger, > initialValue: T) and StaticArray(dimensions: [LiteralInteger], > initialValue: T) That would give away the option of typesafe vector math, which I consider more valuable than the increased performance: I don't want to

Re: [swift-evolution] Yet another fixed-size array spitball session

Without static arrays, swift cannot be used in high performance applications. The cost of repeated heap accesses is simply too high. And tuples are not ergonomic enough to use in the same manner as arrays. So I think we do need to add static arrays to Swift, if not necessarily in Swift 4. My

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 31, 2017, at 4:16 PM, Jean-Daniel wrote: > >> >> Le 31 mai 2017 à 01:47, Anders Kierulf > > a écrit : >> >>> >>> On May 30, 2017, at 3:36 PM, Jean-Daniel via swift-evolution >>>

Re: [swift-evolution] Yet another fixed-size array spitball session

> Le 31 mai 2017 à 01:47, Anders Kierulf a écrit : > >> >> On May 30, 2017, at 3:36 PM, Jean-Daniel via swift-evolution >> > wrote: >> >>> >>> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution >>>

Re: [swift-evolution] Yet another fixed-size array spitball session

> On 30 May 2017, at 16:27, David Sweeris via swift-evolution > wrote: > > On May 30, 2017, at 03:25, Pavol Vaskovic > wrote: > >> On Tue, May 30, 2017 at 7:51 AM, David Sweeris >

Re: [swift-evolution] Yet another fixed-size array spitball session

On May 30, 2017, at 2:32 AM, Charlie Monroe via swift-evolution wrote:Sorry if this has been suggested before, but what is wrong with something alonglet x: Int[4]let x: Int<4>In case of multi-dimension arrays:let x: Int[4][4]let x: Int[4, 4]let x: Int<4><4>let x: Int<4,

Re: [swift-evolution] Yet another fixed-size array spitball session

On May 29, 2017, at 5:39 PM, Nicolas Fezans via swift-evolution wrote:On Mon 29. May 2017 at 20:57, David Sweeris via swift-evolution wrote:> On May 29, 2017, at 01:12, Tino Heth via swift-evolution wrote:>> I

Re: [swift-evolution] Yet another fixed-size array spitball session

On May 29, 2017, at 3:37 AM, Rien wrote:While I’d like a fixed size array, I’d agree with Rod that this looks odd.Myself I use the name ‘array’ a lot in places where I get/need a temporary array that lives for a few lines only. So I am against using the keyword

Re: [swift-evolution] Yet another fixed-size array spitball session

On May 29, 2017, at 3:21 AM, Rod Brown wrote:While I can’t comment about the technical details, I have to say, this looks really “unswifty” to my eye. I’d probably expect something more along the lines of: let x: FixedArray = [1, 2, 3]or: let y: StaticArray = [1, 2,

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 30, 2017, at 3:36 PM, Jean-Daniel via swift-evolution > wrote: > >> >> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution >> > a écrit : >> >> There was someone a few weeks ago trying to

Re: [swift-evolution] Yet another fixed-size array spitball session

> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution > a écrit : > > There was someone a few weeks ago trying to port his Go game to Swift from (I > believe) C++ and found out that the lack of fixed-size arrays was causing the > move-computing algorithm to

Re: [swift-evolution] Yet another fixed-size array spitball session

I agree that Swift absolutely needs a static array type. However, until then, here's a gist to generate the code for a static array struct: https://gist.github.com/rltbennett/8a750aa61d58746b3ca4531b3ca3d0db . Happy coding. (Disclaimer: barely tested.) > On May 30, 2017, at 11:27 AM, David

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 30, 2017, at 03:25, Pavol Vaskovic wrote: > >> On Tue, May 30, 2017 at 7:51 AM, David Sweeris wrote: >> >> `(Int, Int, Int, Int)` isn't *that* horrible compared to "[Int x 4]", but >> would you want to replace "[Int8 x 1]" with the

Re: [swift-evolution] Yet another fixed-size array spitball session

There was someone a few weeks ago trying to port his Go game to Swift from (I believe) C++ and found out that the lack of fixed-size arrays was causing the move-computing algorithm to slow down significantly. This is due to fixed arrays being able to live on stack, while "normal Array" is

Re: [swift-evolution] Yet another fixed-size array spitball session

On Tue, May 30, 2017 at 7:51 AM, David Sweeris wrote: > > `(Int, Int, Int, Int)` isn't *that* horrible compared to "[Int x 4]", but > would you want to replace "[Int8 x 1]" with the multipage-long tuple > equivalent? >  It would be really helpful to my understanding,

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 22:03, Pavol Vaskovic via swift-evolution > wrote: > > I'm sorry if I'm misunderstanding your proposal, but I think Swift already > has "array types whose size is fixed at compile time" called Tuple. Tuples don't support subscripting or

Re: [swift-evolution] Yet another fixed-size array spitball session

I'm sorry if I'm misunderstanding your proposal, but I think Swift already has "array types whose size is fixed at compile time" called Tuple. You seem to go straight into proposing new language syntax, without explaining the motivation. If there were previous discussions of this topic, which do

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 2:39 PM, Nicolas Fezans wrote: > > There are many aspects in the initial proposal that certainly need a more > expert eye than mine. I have one question though. It seems to me that the > constant expressions as known as constexpr in C++11 would

Re: [swift-evolution] Yet another fixed-size array spitball session

On Mon 29. May 2017 at 20:57, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 29, 2017, at 01:12, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I agree strongly that the syntax looks awkward — imho > > var v: Vector >

Re: [swift-evolution] Yet another fixed-size array spitball session

> On May 29, 2017, at 01:12, Tino Heth via swift-evolution > wrote: > > I agree strongly that the syntax looks awkward — imho > var v: Vector > would be a much better fit than > var v array 3 of Int > > As much as I want to have "real" arrays, I don't

Re: [swift-evolution] Yet another fixed-size array spitball session

I agree strongly that the syntax looks awkward — imho var v: Vector would be a much better fit than var v array 3 of Int As much as I want to have "real" arrays, I don't think we should add new keywords for them. ___ swift-evolution

Re: [swift-evolution] Yet another fixed-size array spitball session

While I’d like a fixed size array, I’d agree with Rod that this looks odd. Myself I use the name ‘array’ a lot in places where I get/need a temporary array that lives for a few lines only. So I am against using the keyword ‘array’. A name like SizedArray would seem more in-line with other

Re: [swift-evolution] Yet another fixed-size array spitball session

While I can’t comment about the technical details, I have to say, this looks really “unswifty” to my eye. I’d probably expect something more along the lines of: let x: FixedArray = [1, 2, 3] or: let y: StaticArray = [1, 2, 3] > On 29 May 2017, at 4:37 pm, Daryle Walker

[swift-evolution] Yet another fixed-size array spitball session

Static-Sized Arrays This is a new proposed syntax for handling array types whose size is fixed at compile time. This is a classic kind of type that's still missing in Swift. Like the built-in processor numeric types are mapped to special struct types, any built-in vector types should be mapped