I think I would disagree with that claim. I don't expect it to be a currency type for "normal app/server programming" (whatever that means), but I very much expect it to be a currency type in both embedded Swift and for non-embedded programming that has heavy C interop.
5 Likes
+1 on the proposal, -1 on the naming. I don't know what's better, FixedArray sounds fine to me, although I'd be concerned that people think it's inherently immutable. Buffer<N, Int> would also be fine IMO.
FWIW this would be very useful for things like buffers of audio (or graphics) ā many of the use-cases we have are processing exactly 1024 samples of audio. The upstream functions ensure that this is the case so we know statically what to expect. This should also allow for better compiler optimisations.
4 Likes
Can you comment on the name Inline<let Count: Int, Element> mentioned by @hassila above? I personally think has benefits over Vector because it directly describes the storage in the type's name and composes well with flexible count, fixed capacity InlineArray you mentioned.
5 Likes
I would be surprised if this were ever a currency type in the traditional sense of being a type thatās frequently used in APIs and represents the preferred way of working with data of that kind. Itās very rare than an API should be hard-coding that it only work with a particular array size; functions that want to work efficiently with arrays should take a type like Span. This type will at best be an implementation detail of some currency types.
7 Likes
Itās not uncommon to pass pointers to fixed size arrays in e.g. graphics and games programming. Your shaders are hardcoded to deal with 4-component colors and 3-component vertex data, so your serialization code is hardcoded to traffic in float[3] and float[4]. Itās uncommon to create wrapper types around these. Would we recommend using Span instead of Vector in these cases?
1 Like
I'm not sure I agree that it's uncommon to create wrapper types around these. You certainly should be creating wrapper types for your color, coordinate, and vector data. But no, if you're insisting on not wrapping them, by all means just use this type.
1 Like
Iām telling you from my experience looking at game and graphics code written in C++ that it typically traffics heavily in float[n] and simd::floatN, as well as typedefs like vecN. So Vector<N, Float> will be the currency type for Swift code interoperating with existing C++ code that takes arrays.
Okay. I'm not trying to deny your experience or tell you that you will never interact with code like that. What I'm saying is that that doesn't make it a recommended pattern, and in my mind it shouldn't be thought of as a currency type. We generally promote the use of Int as the currency type for integer data, but that doesn't mean you will never see UInt32 or similar types in APIs.
2 Likes
So would our official recommendation for Swift code be to wrap Vector<N, Float> in a newtype, use a typealias, or use Span<Float> instead?
I can't set an official recommendation. I personally would recommend that people work with that kind of data with strongly-typed wrappers. If you're working with a C++ engine that doesn't already distinguish them, you might need to add some wrapper functions, but in most cases there should be an obvious type to any particular value.
I would like us to do some work to make it easier to bridge those wrappers back and forth in the importer, so that e.g. if you're stuck with using a typedef of std::array<float, 4> in C++, you could just put an attribute on that typedef to make it translate to a Swift type consistently. We're seeing a growing number of usability issues in this space already in C++ because of our (reasonable and well-meaning) decision to be less aggressive by default about bridging.
6 Likes
"Inline" is an adjective. I like nounifying adjectives, verbing nouns etc. as much as anyone, but I don't think it works well in this case -- I would very much prefer not to say that a function returns an "inline of 3 integers"!
Good names also work well in contexts where there is no code voice.
(Additionally, remember that we intend to use Inline as the standard naming prefix for data structure variants with inline storage:
InlineArray<Capacity, Element>,InlineSet<Capacity, Element>,InlineDeque<Capacity, Element>,InlineDictionary<Capacity, Key, Value>,InlineString<Capacity>(?!)- etc. etc.
The vector type we're proposing is not a member of this family, and it isn't much related to any of these. Reusing their prefix as a standalone name would not be helpful, I think.)
12 Likes
I think there's a reasonable argument to be made that the noun is the element type, so that we might deviate from the typical "x of y" phraseology for this type and instead describe such a function as returning "3 inline integers" or "3 integers inline". Just as one might colloquially describe a function returning (Int, String) as returning "int-string" or "an int and a string" rather than "a tuple of int and string". (For that matter, one could also describe the vector version simply as returning "3 integers".)
5 Likes
I agree, I was additionally thinking of this similar to Optional<> which is also not a noun but still makes sense. (It modifies the behavior of the type itās generic over in a certain way - as does Inline)
5 Likes
I rather like Inline for this purpose. If we're worried about overloading the term, we could find a word with similar connotations such as Direct, Immediate, Localā¦ I'm not specifically advocating for one of those words, just throwing them out there as possible alternatives.
3 Likes
As a counterargument, there is nothing any more āinlineā about Vector than any other value type. Just like a struct, it stores all its values inline, and just like a struct, a Vector of reference types does not store those class instances inline. The real meaningful thing this type does is store a fixed-size collection of elements of a particular type as stored properties, and the inline storage could be thought of as just a side effect of it being defined as a struct rather than a class.
7 Likes
Then thatād be Duplicate<> or Multiple<> to riff of Optional<> if we donāt want to highlight the inline nature explicitly?
2 Likes
Me too. Given the inconclusive discussion about Vectorās appropriateness as a currency type, I think having Inline in the name helps with deciding whether to use it in a particular API by highlighting how it differs from all of Swiftās other collection types. Itās neither a COW type nor a reference type, so you only want to use this type when the ABI should force passing each of the values directly.
I think Inline is a good enough name for such a type, but if thereās going to be a whole family of InlineFoo types then it would be confusing to also have a plain Inline<let n, T>. The best I can come up with is InlineBuffer, by analogy and contrast to ManagedBuffer. It also extends well to InlineRawBuffer<let n>, which would be useful for passing to APIs that copy a struct of unknown type to the provided memory region.
4 Likes
Multiple<> sounds pretty good to me. Iād be interested to know if anyone has any specific objections to it.
2 Likes
āThis function returns multiple floatsā
Multiple how? Using a tuple? A parameter pack? An array? A simd type? An async stream?
Using an adjective for Optional works because, having been there from day one, it is unambiguous to talk about āreturning an optionalā.
A fixed-size collection needs a noun as its name, so that we can talk about it as its own unique concept among its counterparts: Array, Set, Span, and so on. And what better name than the one whose Wikipedia page has this as the third paragraph:
The term vector is also used, in some contexts, for tuples, which are finite sequences (of numbers or other objects) of a fixed length.
It does not get any better than this.
8 Likes
I'm probably not adding anything to the discussion at this point, but "multiple" is also a noun. 
I think a lot of the discussion so far is around the fact this term is overloaded in computer science (or rather, in existing programming languages.) I don't think anybody disagrees that Vector can mean this sort of type; people are disagreeing that it does so unambiguously or that it's the first definition that comes to mind.
6 Likes