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?
On Wed, Jan 18, 2017 at 8:48 AM Joe Groff <jgr...@apple.com> wrote: > > > On Jan 18, 2017, at 8:41 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Personally, I don't feel that the problem is big enough to warrant a > breaking change here. > > > > `var` is the general property declaration keyword in Swift for > read-write stored properties and read-only/read-write computed properties. > The fact that you can use `let` in place of `var` under one specific > circumstance (a read-only property backed by a stored variable) doesn't > necessarily make the entire keyword meaningless, IMO. `let` is just a > shortcut for a read-only stored property, and I think dropping it or moving > `{ get set }` elsewhere would be more confusing, since it would be > syntactically inconsistent with how the property is implemented. (Protocol > members look the same as class/struct members with the body removed.) > > > > In general, I'm skeptical of ideas that just aim to protect new or bad > developers from themselves, especially at the expense of consistency. > > `let` more strongly guarantees **immutability**, not just "read-only". var > { get } indicates that the protocol's interface only lets you read, but > provides no guarantee that the implementation can't change the value you > get. The language doesn't have the ability to reason about immutability for > anything other than stored properties yet, but we want to leave syntactic > space for that possibility without muddying the strong guarantee of `let`. > For that reason, protocols only support `var { get }` requirements today. > `let` properties naturally model the requirement since you can read them; > their interface is a superset of the protocol requirement. > > -Joe >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution