<div dir="ltr">Yeah, there will need to be a facility to annotating function purity</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 1:00 PM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
> Sent from my iPad<br>
><br>
>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> I kind of agree with the logic of that, but imagine the following:<br>
>><br>
>> class Test {<br>
>> let hello = “hello”<br>
>> var subject = “world”<br>
>> var phrase: String { return hello + “, “ + subject }<br>
>> }<br>
>><br>
>> In this scenario, “subject” can be changed.. and that changes the result of “phrase”. Things like this are why computed properties are “var”.<br>
><br>
> This example would still be required to be var because it accesses a var in its implementation.<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>> l8r<br>
>> Sean<br>
>><br>
>><br>
>>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> class Test {<br>
>>><br>
>>><br>
>>> let hello = "hello"<br>
>>><br>
>>><br>
>>> let world = "world"<br>
>>><br>
>>><br>
>>> var phrase: String { //why must this be 'var'?<br>
>>><br>
>>><br>
>>> return self.hello + self.<br>
>>> world<br>
>>><br>
>>> }<br>
>>> }<br>
>>> It would be more appropriate for such a read-only, immutable property, to use the "let" syntax, so that its immutability is correctly expressed.<br>
>>><br>
>>> Thoughts?<br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</div></div></blockquote></div><br></div>