> On May 4, 2016, at 3:50 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > on Wed May 04 2016, Matthew Johnson <swift-evolution@swift.org > <mailto: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.
Hmm, I get the feeling that I was arguing your own point back at you. Sorry, Dave, I’m a little slow. :) Still, how would you generate an equality operator for a data structure that requires wrapper classes currently, like a LinkedList? > >> 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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution