<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 7:41 AM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Regardless of which approach we take, it feels like something that needs to be implicit for structs and enums where value semantics is trivially provable by way of transitivity.&nbsp;</span>When that is not the case we could require an explicit `value` or `nonvalue` annotation (specific keywords subject to bikeshedding of course).</div></blockquote><div><br class=""></div><div>There is no such thing as "trivially provable by way of transitivity". This type is comprised of only value types, and yet it has reference semantics:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>struct EntryRef {</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>private var index: Int</div><div><span class="Apple-tab-span" style="white-space:pre">                </span></div><div><span class="Apple-tab-span" style="white-space:pre">                </span>var entry: Entry {</div><div><span class="Apple-tab-span" style="white-space:pre">                        </span>get { return entries[index] }</div><div><span class="Apple-tab-span" style="white-space:pre">                        </span>set { entries[index] = newValue }</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>}</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div><br class=""></div><div>This type is comprised of only reference types, and yet it has value semantics:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>struct OpaqueToken: Equatable {</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>class Token {}</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>private let token: Token</div><div><span class="Apple-tab-span" style="white-space:pre">                </span></div><div><span class="Apple-tab-span" style="white-space:pre">                </span>static func == (lhs: OpaqueToken, rhs: OpaqueToken) -&gt; Bool {</div><div><span class="Apple-tab-span" style="white-space:pre">                        </span>return lhs.token === rhs.token</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>}</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div><br class=""></div><div>I think it's better to have types explicitly declare that they have value semantics if they want to make that promise, and otherwise not have the compiler make any assumptions either way. Safety features should not be *guessing* that your code is safe. If you can somehow *prove* it safe, go ahead—but I don't see how that can work without a lot of manual annotations on bridged code.</div></div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">--&nbsp;</div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>

</div>
<br class=""></body></html>