Right. You could have a protocol X that hypothetically had something like 'let x' in it. If struct S implemented X and let x = 17 and class C implemented X and let x = 42 you now have a let variable that could take on multiple values depending on the implementing type which defeats the whole point of the let in the first place. Not to mention what Dmitri said about protocol implementers calculating the value of the let which would really defeat the purpose. The syntax 'var ... { get }' is much more in line with reality than 'let ...'.<div><br>On Friday, January 29, 2016, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> So what about protocols requiring ‘var … { get }’ syntax for read only properties? Is there some sort of underlying reason for this confusing syntax instead of ‘let …’? Now that Swift allows deferred initialization of lets does this requirement make sense?<br>
<br>
`let` doesn't mean "no setter", it means "constant". For instance, you can't make a `weak let`, because the `weak` implies the variable can be nilled. There's no way to require a constant in a protocol, but if there were one, that's what `let ...` would mean.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div>