> On May 7, 2016, at 6:43 PM, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> If I read Andrew’s post correctly it sounds like it may also be of use to the
> optimizer in some cases.
I’ll just requote Dave’s example, which made perfect sense to me (so I’m not
sure why there’s an argument):
> To me that means, if the behavior of “f” only depends on
> data reachable through this array, and f makes no mutations, then in
> this code, the two calls to f() are guaranteed have the same effect.
>
> func g<T>(a: [T]) {
> var vc = MyViewController(a)
> vc.f() // #1
> h()
> vc.f() // #2
> }
>
> But clearly, the only way that can be the case is if T is actually
> immutable (and contains no references to mutable data), because
> otherwise anybody can write:
>
> class X { ... }
> let global: [X] = [ X() ]
> func h() { global[0].mutatingMethod() }
> g(global)
>
> Conclusion: your definition of PureValue, as written, implies conforming
> reference types must be immutable. I'm not saying that's necessarily
> what you meant, but if it isn't, you need to try to define it again.
Yes, of course. If a PureValue contains a reference it must be immutable or
only mutated when uniquely referenced.
There are other ways to communicate what the optimizer needs. I think the more
interesting question is how users should express the value semantics of their
types.
-Andy_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
