Thanks very much for writing this up, it’s very interesting.
The one thing which I think needs improvement is the Copyable protocol. I think
that this is actually part of a larger problem in Swift, which is that we don’t
expose enough information to generic code for it to operate safely. This goes
back to people asking for a value-equivalent to the “class” or “AnyObject”
magic protocols.
For example, often you would like to wrap a Collection and keep some
information about what it contains. In order to do that generically, you need
to ensure a client can hand you an exclusive view of a collection’s contents,
so you know they will not mutate underneath your feet.
Currently, that means you need a RangeReplaceableCollection because it includes
an empty initialiser which allows you to create a unique copy of the
Collection’s contents. It’s a workaround, but it means we have this unnecessary
protocol requirement in the standard library, and in the implementation, which
is making copies that may not be required. If my CollectionWrapper is
initialised with something which has ValueSemantics, I don’t need to create a
whole new instance with equal contents to ensure exclusivity of those contents.
If this was an Array, for example, I could simply assign it and it would ensure
the underlying contiguous buffer is never mutated.
struct CollectionWrapper<C: Collection> {
var _underlying: C
init(contentsOf other: C) where C: RangeReplaceableCollection {
_underlying = C();
_underlying.replaceSubrange(_underlying.startIndex..<_underlying.endIndex,
with: other)
}
}
// Would love to do this…
extension CollectionWrapper {
init(contentsOf other: C) where C: ValueSemantics {
_underlying = other
}
}
As the proposal notes (with the File example), these are semantic
considerations which go beyond simple struct/class distinctions: structs may
have reference semantics, and classes may have value semantics. Would it be
possible to model Copyable/move-only in terms of two new protocols,
ValueSemantics and ReferenceSemantics, with trivial types/non-trivial types
given appropriate defaults (overridable by the programmer, such as for “File”)?
- Karl_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
