on Wed May 04 2016, Matthew Johnson <swift-evolution@swift.org> wrote:
>> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Wed May 04 2016, Adrian Zubarev <swift-evolution@swift.org> 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. > 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. > > 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution