on Wed May 04 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
> On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > on Wed May 04 2016, Matthew Johnson <[email protected]> wrote: > > On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > on Wed May 04 2016, Adrian Zubarev <[email protected]> > wrote: > > Not sure what to think about the enum cases inside a > protocol (if AnyEnum would > even exist), it could be a nice addition to the language, but > this is an own > proposal I guess. > > We should start by adding AnyValue protocol to which all value > types > conforms. > > Having a way to constrain conformance to things with value > semantics > is > something I've long wanted. *However*, the approach described is > too > simplistic. It's possible to build classes whose instances have > value > semantics (just make them immutable) and it's possible to build > structs > whose instances have reference semantics (just put the struct's > storage > in a mutable class instance that it holds as a property, and don't > do > copy-on-write). > > In order for something like AnyValue to have meaning, we need to > impose > greater order. After thinking through many approaches over the > years, I > have arrived at the (admittedly rather drastic) opinion that the > language should effectively outlaw the creation of structs and > enums > that don't have value semantics. (I have no problem with the idea > that > immutable classes that want to act as values should be wrapped in > a > struct). The language could then do lots of things much more > intelligently, such as correctly generating implementations of > equality. > > That is a drastic solution indeed! How would this impact things like > Array<UIView>? While Array itself has value semantics, the aggregate > obviously does not as it contains references which usually be mutated > underneath us. > > Value semantics and mutation can only be measured with respect to > equality. The definition of == for all class types would be equivalent > to ===. Problem solved. > > Similar considerations apply to simpler wrapper structs such as Weak. > > Same answer. > > Hmm. If those qualify as “value semantic” then what kind of structs and enums > would not? A struct wrapping a mutable reference type certainly doesn’t “feel” > value semantic to me and certainly doesn’t have the guarantees usually > associated with value semantics (won’t mutate behind your back, thread safe, > etc). Sure it does. public struct Wrap<T: AnyObject> : Equatable { init(_ x: T) { self.x = x } private x: T } func == <T>(lhs: Wrap<T>, rhs: Wrap<T>) -> Bool { return lhs.x === rhs.x } I defy you to find any scenario where Wrap<T> doesn't have value semantics, whether T is mutable or not. Alternately, you can look at the Array implementation. Array is a struct wrapping a mutable class. It has value semantics by virtue of CoW. > My expectation is a generic aggregate such as Array would have to > conditionally conform to AnyValue only when Element also conforms to > AnyValue. > > I’m also wondering how such a rule would be implemented while still > allowing for CoW structs that *do* implement value semantics, but do > so while using references internally. > > I am not talking about any kind of statically-enforceable rule, although > we could probably make warnings sophisticated enough to help with this. > > You said the you have arrived at the opinion that the language should > “effectively outlaw” structs and enums that do not have value semantics. That > sounded like static enforcement to me. The language outlaws certain kinds of inout aliasing without providing static enforcement. This is like that. > Maybe you meant we should allow the compiler to assume value semantics > for structs and enums despite the fact that it doesn’t statically > enforce this? That would be one *consequence* of effectively outlawing it. The library could make similar assumptions. > If the compiler can be sophisticated enough to verify value semantics > statically maybe it would be better to have that mechanism be > triggered by conformance to AnyValue rather than for all structs and > enums. Types that conform to AnyValue would receive the benefits of > the compiler knowing they have value semantics, while other uses of > structs and enums would remain valid. Best practice would be to > conform structs and enums to AnyValue whenever possible. > > Another possible advantage of this approach would be allowing > immutable reference types to conform to AnyValue and receive the > associated benefits such as the generated implementation of equality, > etc. > > -Matthew > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
