> On 2 Jun 2017, at 07:38, Robert Bennett <rltbenn...@icloud.com> 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 generics to
> support values as parameters. It's clear that [Int * 4] will be array-like
> and contain four Ints. For multidimensional arrays we could use [Int *
> (2,3)]. For an array of tuples, [(x: Int, y: Int) * 4]. I'm not sure why
> nested static arrays would be needed when multidimentionality is provided out
> of the box, but presumably the syntax would support them; you would just need
> to subscript the arrays one at a time instead of with a single subscript
> operator, e.g., a[i][j] instead of a[i, j].
>
> I'm imagining this syntax working like [T] does now as a shorthand for
> Array<T>, although I'm not sure what [Int * 4] should be short for
> (StaticArray<Int, 4>? Vector4<Int>? ...). Constructors for static arrays
> would be called using [Int * 4](args). I'm thinking the constructors would be
> [T * 4](filledWith: T), [T * 4](filledBy: (Int)->T), and an initializer
> taking a Sequence that fails in some manner on a dimension mismatch.
Even with that syntax I'd say there should be a means of handling it in a
general purpose way.
For example, let's say you defined that syntax as an operator:
func * <T>(lhs: T.self, rhs: Int) -> (type: T.self, size:Int) { return
(type: lhs, size: rhs) }
Now you have an explicit tuple describing what it is you want to do, which the
compiler can now pass to a type during compilation to do with as it pleases. In
this case it would pass to some FixedArray type which can use the type and size
to optimise itself. Not sure on the specifics of how just yet, but point being
to try to make this a part of the language that others can use, rather than
simply being some form of compiler magic.
My reasoning being that it may be useful to have other type operators in
future, and/or other types able to take and use the same information.
For example, I briefly discussed once the possibility of a Float variant whose
compatibility would be limited by its target precision, and use ± as an
operator so that I could define for example:
var a:Float±0.1 = 0.5
var b:Float±0.5 = 5.0
a = b // error; precision mismatch (b's precision is too low to
guarantee accuracy)
b = a // this is fine, as a is "more precise" than b
Now put aside whether that idea is actually useful or not; my point is that I'd
like support for fixed-size arrays to be general purpose, as there are other
possible uses for the same basic capabilities (i.e- type variables).
The key thing really is that we need some way for the compiler to recognise
that a type is being refined somehow, and compile it separately as appropriate.
I mentioned generics style variable passing because to me this is the most
logical way to pass information into a type, not because I want it to be the
default syntax at the call site; I fully support other shorthands for the
actual passing of data, the key for me is being able to leverage the same kind
of type-refining capabilities in my own types, rather than this whole thing
just being focused solely on fixed-sized arrays implemented with compiler magic.
> On Jun 1, 2017, at 7:36 AM, Haravikk via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> 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<T, size:Int> { … }
>>
>> The idea being that we can then use size as a variable anywhere within the
>> code for MyFixedArray, but unlike other variables it is determined at
>> compile time, so should be optimised accordingly. As with generics, setting
>> a type variable effectively creates a variant type so for example, a
>> MyFixedArray<Int, size:3> and a MyFixedArray<Int, size:4> would no longer be
>> directly compatible as they may differ internally.
>>
>> This would be useful not just for fixed arrays, but other possibly type
>> variations as well. Ideally it should be possible to specify a default value
>> for type variables; while this wouldn't be useful for fixed arrays, it may
>> be useful for other type variants.
>>
>> To better suit the specific use-case of arrays, we could also add some
>> useful attributes or keywords, for example, reusing subscript could give us:
>>
>> struct MyFixedArray<T, subscript size:Int> { … }
>> let foo:MyFixedArray[4] = [1, 2, 3, 4] // with T being inferred, this is a
>> shorthand for specifying a size of 4
>>
>> Type variables could also be usable with generics, like-so:
>>
>> // only accept fixed arrays of same or smaller size:
>> func myMethod<FA>(values:FA) where FA:FixedArray, FA.size <= Self.size { … }
>>
>> These are the kind of general purpose capabilities I'd like to see at some
>> point, as the usefulness extends beyond just fixed-size arrays.
>>
>>
>>
>> However, on the subject of fixed-size arrays specifically, one other
>> possibility to explore is the concept of Tuple repetition and subscripting.
>> For example, it would be interesting if we could do things like:
>>
>> var foo:(Int)[4] = 0 // Initialises four Ints, all set initially to zero
>> for i in 0 ..< 4 { foo[i] = i } // values are no 0, 1, 2, 3
>>
>> This can be especially interesting when you get into more complex tuples
>> like so:
>>
>> var bar:(x:Int, y:Int)[10] = (x: 0, y: 0) // Initialises 10 pairs of
>> Ints, all initially set to zero
>> for i in 0 ..< 10 { bar[i].x = i; bar[i].y = i } // here we need to use
>> .x and .y to access the values of each pair
>>
>> Of course this would have the same performance characteristics as standard
>> tuples, but it's an interesting means for creating quick, fixed-size arrays
>> in a flexible way. Part of the idea here is that by subscripting tuples, we
>> avoid the need for a general subscript on all types, keeping that available
>> for use-cases like the above.
>> _______________________________________________
>> 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
