> 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
