Here's the iterator type for a wrapping sequence that removes any duplicate value, even if the subsequent elements aren't next to the first one:
/// An iterator wrapping another and vending each element value at most once.
public struct DuplicateRemovalIterator<Base: IteratorProtocol, Set: SetAlgebra>
where Base.Element == Set.Element {
/// The iterator to be filtered.
var base: Base
/// The elements to exclude from vending.
var denyList: Set
}
extension DuplicateRemovalIterator: IteratorProtocol {
public mutating func next() -> Base.Element? {
while let upcoming = base.next() {
if denyList.insert(upcoming).inserted {
return upcoming
}
}
return nil
}
}
The code works just fine. But what happens if the Set argument is a reference type? Copying wouldn't actually make an independent object. My insertions into the set for accounting purposes has just corrupted an application-level object. Oops. I guess the luser should have not used class types outside of stuff that needs to inherit/use Apple's APIs. (Even then, Apple is trying to minimize that starting with SwiftUI.)
I can/should document it for my wrapping types, but Swift is so weighted to both use value types and to assume user-submitted types are value types that it'll require a lot of documentation. The AnyValue protocol concept is less to find a common interface for value types, but to poison use of reference types.
I think both Any and AnyObject can be used as existential box types. I guess we should do the same for AnyValue; it basically has an implementation like Any, with any optimizations for storing reference-type instances possibly removed.
Yes, I know we've discussed that what we really need to watch out for is value semantics, not value types. (There are ways to provide one without the other.). That's where the request to copy objects comes from. Right now, there is no definitive way to copy objects, because the Swift library assumes that value types and their built-in assignment (along with copy-on-write for inner class-based representations) will be enough. I think only three protocols (FloatingPoint, BinaryInteger, and RangeReplaceableCollection) provide ways to create independent copies of a value. There should be a new set of protocols to flag copy-construction, so we can use said semantic to ensure independent copies.
/// A type whose instances can make independent copies of themselves, but not
/// necessarily detached references to contained objects.
protocol ShallowCopier {
/// Creates a copy of the given instance. Properties or elements that are
/// of reference types may still point to the same instances from the
/// source; otherwise, this instance and the original can modifiy
/// sub-objects independently.
///
/// The initialzer should return `nil` only if there's a connected
/// reference-based resource that shouldn't be shared, like a network port
/// or a large file in virtual memory.
init?(copying original: Self)
}
/// A type whose instances can always make independent copies of themselves,
/// except that reference-based sub-objects may not be necessarily detached.
protocol StrongShallowCopier: ShallowCopier {
/// Creates a copy of the given instance. Properties or elements that are
/// of reference types may still point to the same instances from the
/// source; otherwise, this instance and the original can modifiy
/// sub-objects independently.
init!(copying original: Self)
}
/// A type whose instances can make independent copies of themselves, including
/// at the sub-object level.
protocol Copier: ShallowCopier {
/// Creates a copy of the given instance. Even the sub-objects (*i.e.*
/// properties or elements) should be independent copies from the analogous
/// sub-objects in the source.
///
/// The initializer should return `nil` if there's a connected resource that
/// can't have an independent duplicate, like a network port or a large
/// read-write file in virtual memory.
init?(deeplyCopying original: Self)
}
extension Copier {
// So types conforming to Copier only have to implement one initializer.
public init?(copying original: Self) {
self.init(deeplyCopying: original)
}
}
/// A type whose instances can always make independent copies of themselves,
/// including at the sub-object level.
protocol StrongCopier: Copier, StrongShallowCopier {
/// Creates a copy of the given instance. Even the sub-objects (*i.e.*
/// properties or elements) should be independent copies from the analogous
/// sub-objects in the source.
init(deeplyCopying original: Self)
}
The default numeric and string types should conform to StrongCopier. The default collection types should conform to ShallowCopier, upgrading to one of the others when all of the generic arguments match. The automatic conformance structural, enumeration, and tuple types can have for Equatable, etc. can be extended to ShallowCopier or higher. Yes, this is a lot of busy work for both the Swift and Apple-platform teams, but it should be relatively quick and represents a facility that should have been in Swift 1 or 2.
(If we go up to an ABI Version 2, or add retroactive base protocols, RangeReplaceableCollection should refine ShallowCopier. And conditionally higher if the Element type matches.)
Here's some previous threads I found:
- [Bug?] Reference types and mutating methods
- [Pitch] Non-class type requirements on protocols (eg : struct, : enum)
- Value-type bound protocols?
- Restrict parameter to value type
- AnyValue, Immutable protocols, deprecate “: class” protocol constraint
- Strict Value Semantics
- Is there an existing Protocol to constrain a generic parameter to only trivial types?
- Generic constraint to enforce value type?