on Thu May 05 2016, David Sweeris <davesweeris-AT-mac.com> wrote: >> On May 5, 2016, at 5:01 PM, Dave Abrahams <[email protected]> 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 >>>> <[email protected]> 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 would be pretty strongly opposed to that. That's almost the opposite of what I'm proposing. > 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. The whole point of my proposal is to simplify the model. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
