[Second review] SE-0516: `Iterable`

[benlings]

@ben-cohen

And in general, it might even be helpful for users to know that when they iterate in this way, it is done via borrowing elements (as otherwise they may fret – quite rightly in the case of our current design absent optimizer intervention – that expensive copies of elements might be occurring).

Should borrowing iteration support using borrowing to make this distinction visible?

SE-0516: Borrowing Sequence

Comparing this to the for loop section of the Ownership Manifesto, it seems like the intention there was to use ownership declarations on the iteration variable to distinguish between different types of iteration, e.g. for borrowing employee in company.employees { newCompany.employees.append(employee) } Would this be a way for users of the API to be able to choose whether they want iteration from Sequence or BorrowingSequence? The manifesto also shows generators as the mechanism by which ot…

for borrowing employee in company.employees {
  newCompany.employees.append(employee)
}

This could be used to require borrowing iteration.

• If employees only adopts Iterable (not Sequence), borrowing would be optional and the loop would use borrowing iteration because it's the only one available.
• If employees adopts both Iterable and Sequence, specifying borrowing would then use borrowing iteration, not specifying borrowing would use copying iteration.
• If employees only adopt Sequence (not Iterable), specifying borrowing would be an error. (And not specifying it is the current situation where there is only copying iteration)