I posted this on Erica Sadun's website and she suggested I post it here:
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?
Computed properties, even get-only ones, can return different values
every time. 'let's can't.
Dmitri
On Fri, Jan 29, 2016 at 4:16 PM, Frank Ecsedy via swift-evolution <swift-evolution@swift.org> wrote:
I posted this on Erica Sadun's website and she suggested I post it here:
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?
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
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
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 ...'.
On Friday, January 29, 2016, Brent Royal-Gordon <brent@architechies.com> 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
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@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@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.
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@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@swift.org <mailto:swift-evolution@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@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution--
-- Howard._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If we assume that Swift was changed to be like Scala then:
protocol Stored {
let x = 42
}
Would be equivalent to:
protocol Stored {
var x: Int { get }
static func initX() -> Int
}
extension Stored {
static func initX() -> Int { return 42 }
}
If you then implemented the protocol:
struct S: Stored {
var x = 69 // Could be `let` instead of `var`
}
Would be equivalent to:
struct S: Stored {
var x = S.initX()
static func initX() -> Int { return 69 }
}
Therefore it is possible to unify the two concepts.
On Saturday, 30 January 2016, <davesweeris@mac.com> wrote:
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@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution--
-- Howard._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.