+1 for Vector. I find the arguments against it to be mostly speculative and unconvincing.
As a second choice, I really like Run - it just seems to click with me. Not so much any of the suggestions based on Array or Tuple.
3 Likes
Sure, but before you explained what the criteria for an array were, it wasnât clear why youâd made this decision. Personally, I had guessed that you were avoiding the word âarrayâ because these types are views on storage owned by another type.
2 Likes
Among all alternative names I prefer Slab.
Interestingly, in later versions of Pascal/Delphi the concept of array was extended to include variable-sized ones: simply array of Integer means "dynamic" array. So I'd vote for the word Array in the new name in Swift, with some prefix.
1 Like
+1 for Vector. It matches the use in mathematics in particular. I can see myself using it my own vector classes, such as this which is named similarly because of its mathematical purpose:
struct Vector2D {
let x: Double
let y: Double
// ...
}
Replacing x and y with Vector<2. Double> would have a few benefits, mostly in code clarity, especially when applied to a group of classes.
It doesn't match other languages no, but nor do many other things in Swift, in particular Array. With that not available Vector is best.
It certainly should not be called FixedArray or similar. It's a fundamental type not a derived one, and that in particular would be confusing, looking like a subclass of Array.
A few other concise names have been suggested but there seems to be no consensus over them, or even over how one might be chosen.
3 Likes
Others have already pointed out that this is not an efficient implementation of a Vector2D. While in my experience LLVM is pretty good at optimizing such uses into vector instructions, it doesn't have to.
You should use the SIMD types not the new Vector type as storage in your Vector2D.
3 Likes
I briefly suggested Run myself a couple days ago before deleting the post because of the inescapable confusion with the verb "to run". Best to just not touch that IMO.
I see no downside to Series.
However I would be fine with Vector. Any would-be conflicting types in math contexts could use the abbreviation Vec / Vect without too much trouble.
If I needed performance yes but that is not the focus of this class. In fact the way it's used SIMD might even be slower.
- If the vector instructions were to be slower in some situation I believe LLVM would just choose not to use them as an optimization. And if for some reason it still is slower, you should confirm it with benchmarks
- In Swift terminology this is not a class. Unlike certain other languages Swift uses the term as intended in object oriented programming.
2 Likes
I do know that. not sure why I wrote it so.
1 Like
If "vector" is the preferred name but might conflict with other uses of the word, why not use a foreign ASCII-compatible spelling? "Vektor" is common to many languages, or to avoid favouring any countries there is "Vektoro" in Esperanto.
Oh I actually love Series. That to me feels the best out of all the non-Array/Vector names by far.
3 Likes
If we fault Vector for elements not being of a vector space, surely we must also fault Series for elements not being summands?
4 Likes
I sure find myself dealing with std::vector and Vector2D in the same program more than I deal with any sort of data type that embodies the concept of a sum.
Once I reached the end of this thread, I noticed this little nugget:
Even the introduction of this new data type had to explain what it was in terms we all understood. It could have been introduced as "Huitzilopotchtli, a fixed-size array" and we would have known what it Huitzilopotchtli was.
There is little value in forcing all this churn, pain and angusih in the community for what was clearly a FixedArray from the start
16 Likes
Sureâbut is that a proper measure of correctness? Iâd say no: otherwise, Kitchen would be a far better name than all of these, because I am likely never to find myself dealing with my kitchen and this type in the same program.
This goes to @lorenteyâs argument that a description is not a name. After all, we describe Array as âan ordered, random-access collectionâ and we definitely wouldnât say that ought to be called OrderedRandomAccessCollection.
But on that note: we should, indeed, retitle this proposal to read â(Name of type), an ordered random-access collection of fixed count.â
Anywayâimplicit in your argument, I take it, is that there exists no ânameâ of the sort that @lorentey seeks which is meaningfully more legible than âHuitzilopotchtliâ to users and that we ought not to even try. I would say that Iâm in the camp that Vector is such a name and that, with sufficient exploration, we might identify appropriate alternatives too if we donât like that one.
But maybe not! My sense is that there is more consensus that we havenât found one clearly superior to Vectorâand where we differ is whether procedurally in that case this means we then go with the best on offer or we go with a âdescription.â I donât think we have consensus on that point.
5 Likes
Just call it array and put a something like @Fixed attribute before (it could be a macro that changes its name for all I care hehe).
I wasn't even thinking of it in mathematical terms; like I believe @beccadax said, I thought about it more in terms of "TV series" or "a series of events". I can't help but think about Vector in mathematical terms, whereas I have to be reminded that Series is a mathematical term as well.
I get the clear feeling the core team is going to have to hash this one out, as I feel the community is starting to go around in circles here and the members of the Swift team don't seem to agree on the right direction yet. Good thing today's the last day of the second review, I suppose. 
2 Likes
I stumbled on this late but it's the kind of exhausting nonsense that makes tons of people not want to participate here.
I think Vector is a bad name. I have an EE degree, so plenty of higher math, have been a Mac developer for ~20 years, and have written a fair bit of code that uses vectors (in the broad linear algebra sense, not just geometry). I still find that name confusing when used to refer to anything other than a geometric direction and magnitude.
I don't actually care much what the name is as long as it isn't Vector. FixedArray seems fine. I can look at it with no prior knowledge and guess correctly what it does. Having taught Swift professionally for a number of years, I can say with confidence that teaching students what a "Vector" is going to be more confusing than just presenting them with a "FixedArray". But other OK names have been proposed here too.
On the discussion about "array" implying mutability, mutability is obviously not a fundamental characteristic of arrays. People arguing that it is honestly baffles me. I mean, arrays are immutable by default in ObjC even!
13 Likes
It's very obviously not, given that numerous long-time serious contributors to this forum have given long, thought-out explanations of their thinking in favor and against both Vector- and Array-derived names. Calling the effort they've put into that "exhausting nonsense" is frankly pretty rude.
I think we all wish that we could just agree on a name, but there's only three ways that really happens:
- We agree to use the name that the proposal authors--the people who have spent the most time wrangling with the type, who have the most informed opinions with regard to the narrow naming considerations--propose.
- We have a long somewhat frustrating conversation to hash it out here, involving not only the proposal authors, but also a broad sample of the users who will adopt these types in the future.
- We give up and ask the LSG--presumably a sample of people who spend a lot of time thinking about the language's conventions broadly, and its future trajectory, therefore the broadest considerations--to just pick the name they think is best.
We might very well end up with option 3, but the other two are also perfectly valid paths to navigate the process, and I think are generally the approaches that we want to try first when faced with these problems.
25 Likes