on Sat May 07 2016, Andrew Trick <atrick-AT-apple.com> wrote: > On May 7, 2016, at 2:04 PM, Dave Abrahams <[email protected]> wrote: > > 2. Value types are not "pure" values if any part of the aggregate > contains a > reference whose type does not have value semantics. > > Then Array<Int> is not a “pure” value (the buffer contained in an > Array<Int> is a mutable reference type that on its own, definitely does > *not* have value semantics). I don't think this is what you intend, and > it indicates that you need to keep working on your definition. > > It sounds like you’re changing the definition of value semantics to make it > impossible to define PureValue.
Not on purpose. > Does Array<T> have value semantics then only if T also has value > semantics? This is a great question; I had to rewrite my response four times. In my world, an Array<T> always has value semantics if you respect the boundaries of element values as defined by ==. That means that if T is a mutable reference type, you're not looking through references, because == is equivalent to ===. Therefore, for almost any interesting SomeConstraint that doesn't refine ValueSemantics, then Array<T: SomeConstraint> only has value semantics if T has value semantics, since SomeConstraint presumably uses aspects of T other than reference identity. > The claim has been made that Array always has value semantics, > implying that the array value’s boundary ends at the boundary of it’s > element values. Yes, an array value ends at the boundary of its elements' values. > That fact is what allows the compiler to ignore mutation of the > buffer. I don't know what you mean here. > It's perfectly clear that Array<T> is a PureValue iff T is a PureValue. > PureValue is nothing more than transitive value semantics. You're almost there. “Transitive” implies that you are going to look at the parts of a type to see if they are also PureValue's. So which parts of the Array struct does one look at, and why? Just tell me the procedure for determining whether a type is a PureValue. > At any rate, we could add a PureValue magic protocol, and it would have > well-defined meaning. I'm not sure that it is worthwhile or even a good way to > approach the problem. But we don't need to argue about the definition. I don't want to argue about anything, really. I just want a definition. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
