[Second review] SE-0483: `InlineArray` Type Sugar

Evolution Proposal Reviews
23

Apologies for not answering your explicit questions. I side stepped them directly before because there is a fallacy in them that using InlineArray will consistently lead to faster more efficient code that I found a bit distracting, but that is not what I took as its heart. (Ben wrote some really good stuff about that in the last pitch (A, B).)

What I liked about it your post and what I think you've got right is that the question should now be about a potential sugar's ergonomics in code bases based on how the type will actually be used by people who will actually use it with of as the spelling. Some of that can't be done until its out there being used, in my opinion.

To pull out your answer to 3 as background information I use Swift in conjunction with C a lot. It is an absolute dream until one gets to C Arrays. I am very anxious for InlineArray to keep on keeping on so we can fix the TupleMuddle that the language has been in since the beginning. Although the current InlineArray doesn't get us quite all the way there, I have been watching it for a very long time with a lot of attention because it is a barrier between me and getting to use Swift for actual production code and also between me and feeling comfortable on trying to sell my embedded hardware / video pixel munching friends on Swift. The shady shady things I currently do with memcpy and assumptions about memory binding...

  1. InlineArray<5, Int> suffices just fine
  2. It should be consistent with the [1, ...., 1] syntax.
  3. See above.
  4. Also see above, although there are many other situations. Lots of good reading in the InlineArray pitch threads! Look for Vector, but I too would be interested in hearing people share again if they have the time.

Thanks for your all your answers to what I wrote. It is interesting to hear the perspective of someone who is less attached to the type. That's a useful perspective!

I don't think one should need the brackets in the print example. Variadics are a thing after all the below currently works.

let x = "hello"
print(x, x, x)

In the previous pitches lots of people mused about using of in different contexts.... I can go pull some of those out but maybe not this week! It's got a nice sentence like Swifty flow in some contexts. I missed of being less commutative, but I've missed things before. I'll go back and reread the pitch.

I think we disagree that it's okay for [1, 1, 1, 1, 1] and [5 of 1] to mean different things. which is a reasonable thing to disagree about.

I agree that var a: [Int] = [5 of 1] should be allowed ant that another thing mentioned above should also be allowed let fourIntegers: InlineArray = [1,2,3,4]

I would say the following would be what I'd like to be able to do / expect to have happen.

var currentRepeatedArray = [1, 1, 1, 1, 1] // Array
var quickerArray = [5 of 1] //Array
var repeatedInline: InlineArray = [1,1,1,1] //InlineArray
var quickerInline: InlineArray = [5 of 1] //InlineArray
var explicitQuickArray: [Int] = [5 of 1] //Array

I do not have a expectation or a burning desire for being able to use get any shorter InlineArray at this time. Type sugar doesn't get me much if it isn't the literal, and I think the literal this type sugar implies leads to confusions that could have significant negatives in performance because one of these type ISN'T always the best go to.

You don't seem to find that [1, 1, 1, 1, 1] != [5 of 1] as off putting as I do and that's good to know.

3 Likes