<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 May 2016, at 18:00, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I kind of agree with the logic of that, but imagine the following:<br class=""><br class="">class Test {<br class="">let hello = “hello”<br class="">var subject = “world”<br class="">var phrase: String { return hello + “, “ + subject }<br class="">}<br class=""><br class="">In this scenario, “subject” can be changed.. and that changes the result of “phrase”. Things like this are why computed properties are “var”.<br class=""></blockquote><br class="">This example would still be required to be var because it accesses a var in its implementation.<br class=""><br class="">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 class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><div><br class=""></div><div>Even if a “computed” property were immutable, do we really want to implicitly make it a constant as well? Take for example:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><div style="margin: 0px;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">class</span> Test {</div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> a:[<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>]</div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> b:[<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>]</div><div style="margin: 0px; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">init</span>(<span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">_</span> value:<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>) {</div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">a</span> = <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Array</span>(count: <span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">65536</span>, repeatedValue: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>(value))</div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">b</span> = <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Array</span>(count: <span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">65536</span>, repeatedValue: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>(value &+ <span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">1</span>))</div><div style="margin: 0px;" class=""> }</div><div style="margin: 0px; min-height: 13px;" class=""><br class=""></div><div style="margin: 0px;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> combined:[<span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int64</span>] { <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">return</span> <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">a</span> + <span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">b</span> }</div><div style="margin: 0px;" class="">}</div></div></div></blockquote><div><br class=""></div><div>Each of these arrays is 512kb, so storing a fixed value for the combined property would require another megabyte of space per instance of Test, but if the combined property is only infrequently called on some instances of Test, then it would be a waste of memory to precompute it, especially if you’re dealing with thousands of instances, with only a fraction of them calling the computed property. If you want to accelerate usage of the computed property then that’s what lazy variables are for, as you can delay the expensive combination until you actually need it.</div><div><br class=""></div><div>The problem really is that the compiler can only do limited analysis about whether a computer property is used a lot, and in most cases it doesn’t care (it only really cares whether something is unused, as it can try to optimise it away), to make a good decision it would need to run the program with a realistic test-case an analysis memory overhead and performance impact of each method.</div><div><br class=""></div><div>So yeah, I’m not really sure of the advantage of this, unless the intention is purely to restrict what can be used within your computed property’s implementation, but I don’t think the compiler can realistically do much in the way of optimising stuff away as precomputed values need to be stored somewhere, which could mean making your type bigger, which begs the question of why you specified a computed value in the first place.</div><div><br class=""></div><div>I guess I’m just confused as to what the problem being solved would really be.</div></body></html>