A roadmap for improving Swift performance predictability: ARC improvements and ownership control

Evolution Pitches
11

Yeah that's kind of what I'm worried about; that nobody is going to remember these rules (which might even change in the future as new cases are discovered and features added), and just think:

(I left out the part about caring about uniqueness; it's not always clear if you care about uniqueness - or at least, it's not always clear that you don't need to care).

So then users will think "Hey, I have this great idea for a new collection!", then they'll look at swift-collections (or package X), see a bunch of moves in almost every function across the entire library, and think "gosh, there's something really intricate going on here and I don't understand it; I'm out of my depth and shouldn't contribute to this package".

It may be an unavoidable consequence of achieving predictable performance, but it's still unfortunate.

Anyway, I'll wait for the lexical lifetimes proposal. From the brief description here, I really like it.

I wonder -- and this is a totally oddball idea that I absolutely have not thought through -- if the goal is just to communicate some performance assertions to the compiler that it could diagnose, why not just write those as some kind of assertion? In as close to real English as possible.

I guess this ultimately becomes a question of syntax and how well concepts are communicated in source code. The ideas floated in the move proposal about adding a drop(x) or assert(no longer using x) to mark the end of a lifetime is a lot more attractive in light of this manifesto.

// Instead of writing:
init(_ values: [String]) {
  // OMG what does 'move' do? This is some low-level performance intrinsic - eek!
  self.values = move(values)
  self.values.sort()
}

// You'd write something more like:
init(_ values: [String]) {
  self.values = values
  // Oh, ok, they want to check that 'values' is no longer being used.
  // It isn't required for correctness. It's just a check.
  #assert(no longer using 'values')
  self.values.sort()
}

This would be a lot more familiar to Swift developers who aren't ready to get in to the weeds about move semantics and ownership. It's just regular Swift, with some additional assertions to the compiler which are very approachable -- the reason for them being there might be a bit opaque, but no more opaque than having 'move' dotted about everywhere.

6 Likes