> 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 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.
K&R in their original C decided to make arrays a low-level type, are removed
the mid-level features other languages had for their arrays. I’m deciding in
the opposite direction, allowing FSAs to be mid-level types, and adding (back)
features appropriately.
Also, a core goal of FSAs is a user gateway to processor vector-unit types, and
I didn’t want to ban 2D vector unit types (if they exist).
> 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.
I originally used standard array literals for FSAs. And other people complained
about that!
The problem is that the only way to know if an array literal is supposed to go
to a FSA instead of an instantiation of Array is the surrounding context. And
some people didn’t like that; they wanted the type to be (almost) always
determined by the literal alone. In the old way, I needed a “let x: [_: Int] =
[1, 2, 3, 4]” wildcard construct to allow automatic determination of the
length. By including the array shape, we can differentiate FSAs from Array.
—
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
