> On May 7, 2016, at 7:07 PM, Andrew Trick <atr...@apple.com> wrote: > > >> On May 7, 2016, at 2:04 PM, Dave Abrahams <dabrah...@apple.com >> <mailto:dabrah...@apple.com>> 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. Does Array<T> have value semantics then only > if T also has value semantics? > > 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. That > fact is what allows the compiler to ignore mutation of the buffer. > > It's perfectly clear that Array<T> is a PureValue iff T is a PureValue. > PureValue is nothing more than transitive value semantics. > > 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.
Thanks for jumping in again. I hope we can get past the discussion of definition! Are you speaking specifically about this being of use to the optimizer or about the value of such a protocol in general? For example, if we introduce a notion of pure functions into the language wouldn’t it be useful to be able to write generic pure functions by constraining the argument types to PureValue? IMO this property is important enough that the ability to express it directly in code (rather than documentation) and to take advantage of it in generic code is very desirable. A PureValue protocol seems like a good way to do this but I am certainly open to other solutions as well. Long term it would be really nice if Swift had a logically pure subset and the ability to clearly distinguish code that lives inside that world from code that is outside that world. I say “logically" pure because I think implementation techniques like CoW, memoization, etc are very valuable and do not violate the spirit of purity despite the fact that they rely on side effects. -Matthew > > -Andy
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
