<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I've been thinking about this further and can now state my position more clearly and concisely.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">1. If we're going to have reference types with value semantics the boundary of the value must extend through the reference to the value of the object. Two instances may have the same logical value so reference equality is not good enough.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">2. Value types are not "pure" values if any part of the aggregate contains a reference whose type does not have value semantics. Purity must include the entire aggregate. Array<UIView> has value semantics but it is not a pure value.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">The primary reasons I can think of for creating reference types with value semantics are avoiding copying everything all the time or using inheritance. (I could also list pre-existing types here but am not as concerned with those)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">One could argue that you can avoid copying by writing a struct with a handle and one can simulate inheritance by embedding and forwarding. The problem is that this involves a lot of boilerplate and makes your code more complex. For something like the standard library these concerns are far outweighed by the benefit we all gain by having our collections be value types. However, in application code the benefit may not be worth the cost thus it may be reasonable to prefer immutable objects.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think there is a viable path for enhancing the language such that there is little or not reason to implement a value semantic type as a reference type. If we were able to declare value types as "indirect" and / or have a compiler supported Box (probably with syntactic sugar) that automatically forwarded calls, performed CoW, etc this would allow us much more control over copying without requiring boilerplate. We could also add something along the lines of Go's embedding (or a more general forwarding mechanism which is my preference) which would likely address many of the reasons for using inheritance in a value semantic reference type.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If we do go down that path I think the case that value semantic types should be implemented as value types, thus reference equality should be the default equality for reference types gets much stronger. In that hypothetical future Swift we might even be able to go so far as saying that reference types with value semantics are an anti-pattern and "outlaw" them. This would allow us to simply say "reference types have reference semantics". </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">We might also be able to get to a place where we can "outlaw" value types that do not have value semantics. I haven't thought deeply about that so I'm not certain of the implications, particularly with regards to C interop. IIRC Dave A indicated he would like to see this happen. If this is possible, we may eventually have a language where "value types have value semantics", "some value types are pure values", and "reference types have reference semantics and are never pure values". If it is achievable it would be a significant step forward in simplicity and clarity. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Matthew</div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On May 7, 2016, at 11:17 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br>Sent from my iPad</div><div><br>On May 7, 2016, at 2:21 AM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I don’t mean to imply that it is the *only* valuable<br class="">property. However, it I (and many others) do believe it is an extremely valuable<br class="">property in many cases. Do you disagree?<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think I do. What is valuable about such a protocol? What generic</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">algorithms could you write that work on models of PureValue but don't</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">work just as well on Array<Int>?</span></div></div></blockquote></div><br class=""><div class=""><div class="">class Storage {</div><div class=""> var element: Int = 0</div><div class="">}</div><div class=""><br class=""></div><div class="">struct Value {</div><div class=""> var storage: Storage</div><div class="">}</div><div class=""><br class=""></div><div class="">func amIPure(v: Value) -> Int {</div><div class=""> v.storage.element = 3</div><div class=""> return v.storage.element</div><div class="">}</div><div class=""><br class=""></div><div class="">I (the optimizer) want to know if 'amIPure' is a pure function. The developer needs to tell me where the boundaries of the value lie. Does 'storage' lie inside the Value, or outside? If it is inside, then Value is a 'PureValue' and 'amIPure' is a pure function. To enforce that, the developer will need to implement CoW, or we need add some language features.</div></div></div></blockquote><div><br></div><div>Thank you for this clear exposition of how PureValue relates to pure functions. This is the exact intuition I have about it but you have stated it much more clearly.</div><div><br></div><div>Language features to help automate CoW would be great. It would eliminate boilerplate, but more importantly it would likely provide more information to the compiler.</div><br><blockquote type="cite"><div><div class=""><div class=""><br class=""></div><div class="">If I know about every operation inside 'amIPure', and know where the value's boundary is, then I don't really need to know that 'Value' is a 'PureValue'. For example, I know that this function is pure without caring about 'PureValue'.</div><div class=""><br class=""></div><div class="">func IAmPure(v: Value, s: Storage) -> Int {</div><div class=""> var t = v</div><div class=""> t.storage = s</div><div class=""> return t.storage.element</div><div class="">}</div><div class=""><br class=""></div><div class="">However, I might only have summary information. I might know that the function only writes to memory reachable from Value. In that case, it would be nice to have summary information about the storage type. 'PureValue' is another way of saying that it does not contain references to objects outside the value's boundary (I would add that it cannot have a user-defined deinit). The only thing vague about that is that we don't have a general way for the developer to define the value's boundary. It certainly should be consistent with '==', but implementing '==' doesn't tell the optimizer anything.</div></div></div></blockquote><div><br></div><div>I think the ability to define the value's boundary would be wonderful. If we added a way to do this it would be a requirement of PureValue.</div><br><blockquote type="cite"><div><div class=""><div class=""><br class=""></div><div class="">Anyway, these are only optimizer concerns, and programming model should take precedence in these discussion. But I thought that might help.</div></div></div></blockquote><blockquote type="cite"><div><div class=""><br class=""></div><div class="">-Andy</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></body></html>