Yeah I’m looking for that day too. :) class ImmutableThing : AnyValue { … }
-- Adrian Zubarev Sent with Airmail Am 18. Januar 2017 um 18:03:59, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: On Jan 18, 2017, at 11:00 AM, Joe Groff <jgr...@apple.com> wrote: On Jan 18, 2017, at 8:57 AM, Matthew Johnson <matt...@anandabits.com> wrote: On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote: On Jan 18, 2017, at 8:50 AM, Tony Allevato <tony.allev...@gmail.com> wrote: Good point—I hadn't considered the distinction. Does that mean a future version of Swift might allow `let` in a protocol to indicate a value that must be immutable after initialization, such that a computed `var { get }` wouldn't satisfy it? It's conceivable that even computed `let` properties could be supported, if the getter implementation is a pure function of `self`. How would that work when `self` is mutable? The exact meaning of "pure" and "immutable" would have to be designed. To a first approximation, you could say a pure method would only be able to read immutable global or class data (which is itself `let` or `pure func`, not anything that's potentially mutable) in addition to its own arguments. Got it. That makes sense. Looking forward to the expanded pure / immutable model someday! -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution