[swift-evolution] Protocols and var { get }

davesweeris at mac.com davesweeris at mac.com
Sat Jan 30 01:29:00 CST 2016


Not really… There’s a pretty big difference between “no setter” and “const". Plus, since we’re talking about protocols, “var … {get}” doesn’t even mean “no setter”, it means “no setter required”. A regular var property (which is obviously not constant) can satisfy a {get} requirement.

- Dave Sweeris (Non-Canonical Dave)

> On Jan 29, 2016, at 22:49, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Scala uses their equivalent of let ... instead of var ... { get }. In Scala let ... Always means var ... { get }. Not a problem in Scala only having one concept. I think it is a possibility for Swift.
> 
> On Saturday, 30 January 2016, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > 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?
> 
> `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.
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> -- 
>   -- Howard.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/0b547d0d/attachment.html>


More information about the swift-evolution mailing list