[swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Joe Groff]

> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I kind of agree with the logic of that, but imagine the following:
>> 
>> class Test {
>> let hello = “hello”
>> var subject = “world”
>> var phrase: String { return hello + “, “ + subject }
>> }
>> 
>> In this scenario, “subject” can be changed.. and that changes the result of “phrase”. Things like this are why computed properties are “var”.
> 
> This example would still be required to be var because it accesses a var in its implementation.
> 
> I like the idea of allowing this feature, but only in cases where the compiler can verify immutable semantics.  Having it may help drive other features that could expand the cases the compiler can verify.  That would be great as this is a direction I would like to see Swift take in the future.

Yeah, this is why we don't currently allow computed "let" properties. We'd only want to do so once we have the language facilities to ensure a computed 'let' property is immutable and has no observable side effects.

-Joe

>> 
>> l8r
>> Sean
>> 
>> 
>>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I came an interesting SO question which pointed out a strange quirk: a computed property must always use the "var" keyword, even if it's read-only, and only referencing other immutable data.
>>> 
>>> class Test {
>>> 
>>> 
>>> let hello = "hello"
>>> 
>>> 
>>> let world = "world"
>>> 
>>> 
>>> var phrase: String { //why must this be 'var'?
>>> 
>>> 
>>> return self.hello + self.
>>> world
>>> 
>>> }
>>> }
>>> It would be more appropriate for such a read-only, immutable property, to use the "let" syntax, so that its immutability is correctly expressed.
>>> 
>>> Thoughts?
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution