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

[Matthew Johnson]

Sent from my iPad

> On May 11, 2016, at 1:02 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>>> On 11 May 2016, at 18:00, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 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.
> 
> 
> Even if a “computed” property were immutable, do we really want to implicitly make it a constant as well? Take for example:
> 
> class Test {
>     let a:[Int64]
>     let b:[Int64]
> 
>     init(_ value:Int64) {
>         self.a = Array(count: 65536, repeatedValue: Int64(value))
>         self.b = Array(count: 65536, repeatedValue: Int64(value &+ 1))
>     }
> 
>     var combined:[Int64] { return a + b }
> }
> 
> 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.
> 
> 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.
> 
> 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.
> 
> I guess I’m just confused as to what the problem being solved would really be.

It provides semantic clarity in the API contract.  If you look at the property now and then look at it again at some point in the future you will get the same value back.  'var { get }' does not allow for that.  I imagine we would be able to specify 'let' protocol requirements as well which could be implement with either stored or computed 'let' properties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/1b960e01/attachment.html>