Sent from my iPad
> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution
> <swift-evolution@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.
>
> l8r
> Sean
>
>
>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution
>> <swift-evolution@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
