<div dir="ltr">I agree with pretty much everything you said, although I&#39;m not saying we should &quot;solve&quot; this, but that we should discuss it. One thing we might be able to do is instead of trusting the person writing the type to:<div><ul><li>&quot;<span style="font-size:13px">provide the expected semantics, or to document any deviations</span>&quot;<br></li></ul></div><div>we may trust the person writing the type to:</div><div><ul><li>&quot;<span style="font-size:13px">annotate the type with the expected semantics</span>&quot;<br></li></ul></div><div>If such annotations existed. It wouldn&#39;t force everything to be c-like, but it could allow them to be predictable.</div><div><br></div><div>I&#39;m not saying annotations are the way to go, just that there is an issue, you seem to agree, and that it&#39;d be nice to brainstorm it.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 1:42 AM, Brent Royal-Gordon <span dir="ltr">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; TL;DR: You can make a struct look like a class, a class look like a struct, a mutable type appear immutable.<br>
<br>
</span>This is simply not possible to prevent, at least without turning structs into dumb data structures a la C. Here’s something that’s value types all the way down, but behaves like a reference type:<br>
<br>
        struct MyValue {<br>
            private static var realValues: [Int] = []<br>
            private let index: Int<br>
<br>
            init(value: Int) {<br>
                self.index = MyValue.realValues.count<br>
                MyValue.realValues.append(value)<br>
            }<br>
            var value: Int {<br>
                get { return MyValue.realValues[index] }<br>
                set { MyValue.realValues[index] = newValue }<br>
            }<br>
        }<br>
<br>
Similarly, you can make reference types with value-like semantics—think of NSDate, which is a reference type, but is immutable and only provides operations which return a new instance. The ultimate proof of this is not in Swift but in Ruby, where even simple numbers are objects, but they offer no mutation operations so they behave just like value-typed numbers in other languages.<br>
<br>
Ultimately, you just have to trust the person writing the type to provide the expected semantics, or to document any deviations. (GeneratorType, which does not require even struct-based generators to guarantee that they will iterate separately if you copy them, are an example of the latter.) This leaves room for mischief, but that’s life in a Turing machine.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div>