I’m a +1 for the proposal (but as I’ve implemented a bunch of collections
recently I’m not sure I’m looking forward to having to update my code to
reflect the new pattern ;)
But I’m interested by these concerns:
> On 12 Apr 2016, at 17:57, plx via swift-evolution <[email protected]>
> wrote:
>
> # 1: Relatively Unsafe, Pointer-Like Semantics
> # 2: Index Invalidation Unrepresented In Type System
It seems to me as though we could solve #1 by solving #2 actually; if we knew
when indices were invalid, then unless we’re storing .endIndex or using
.startIndex or .endIndex on an empty collection (rather than .first and .last)
then there should no issues of the safety of these “pointers" anymore.
The tricky thing is how to handle #2; we can do this at run-time by having
indices include a reference to their parent (or some kind of ID class), plus a
copy of a state variable which the collection will use to track invalidating
changes. If an index is passed to the collection with an incorrect reference
then it wasn’t for that collection, and if the states don’t match then the
index was invalidated. But really it’d be better if we had some way to do this
at compile-time which I think is what you meant; i.e- some way for the compiler
to track when an index was invalidated between being stored and being used, so
that passing it into the subscript or other methods will produce a warning.
I suppose this could be done using attributes on the return values for index
generating properties/methods to assign some kind of tag which other methods
can then mark as having been invalidated, so that anything assigned that tag
can be considered invalid by the compiler if you try to use a value stored
before the invalidation. This is something that could be done afterwards I
think, so hopefully shouldn’t affect the proposal itself. There’ll be limits to
how far the compiler can track this though, but it could help to avoid most of
the simpler mistakes at least.
It’d be interesting if the compiler would also trace that an index belongs to a
collection, to prevent you accidentally using compatible ones with the wrong
collection when you have several; it’s good practice to check this with
preconditions, or assertions for performance, but the compiler doing it could
give more useful errors/advice.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
