> On May 5, 2016, at 5:01 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > > on Wed May 04 2016, David Sweeris <davesweeris-AT-mac.com> wrote: > >>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> 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. >> >> You mean that a struct's properties would have to have value >> semantics, too? > > Either that, or you'd have to implement CoW, or you'd not use the > storage behind any properties that were references in a way that affects > value semantics. > >> I think I'm okay with that, especially if it's done through new types >> of structs/enums. > > New types of structs/enums? What does that mean? I meant leave `struct` and `enum` the way they are, and introduce a `different_struct` and `different_enum` (placeholder names, of course) which enforced the “no reference-semantics” rules.
I’m inclined to think we should adopt your “no reference-semantics” rule, but I’m not entirely sure what the impact would be. Adding new types side-steps the issue, at the cost of increasing the complexity of the language/compiler. I’m unsure if that'd be a worth-while trade-off. - Dave Sweeris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
