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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 18, 2016, at 8:17 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 18 May 2016, at 10:08, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> `lazy` properties can't be `let`. Personally, I disagree with this — their 
>> initial mutation is transparent, and it's conceptually perfectly valid to 
>> have a value that's, say, too expensive to calculate during every instance's 
>> init and whose value never changes once calculated — but there may well be 
>> Very Good Reasons for needing them to be `var`.
> 
> You can kind of do this already by adding private(set) to a lazy property, 
> but yeah, the ability to define it as let would be more concise, work within 
> the same type/file and possibly be more intuitive as well. Really it’s just 
> an indicator to the compiler that a value shouldn’t be mutated so it can stop 
> you, though there are some optimisations that can be done as well, many of 
> these may not apply to lazy properties due to the way that they work.

Yep, there are two parts to this.  One is that the current 'let' model is 
extremely strict and thus excludes lazy because it is written to after the 
instance is initialized.  Following from this is the assumptions it allows the 
optimizer to make.

We discussed relaxing 'let' rules in the memberwise init discussion thread.  
The core team seems to be willing to consider this with respect to the issue 
that came up there.  

I think a similar case could be made for lazy let, and more generally 
distinguishing the programmer model of immutability from the optimizer model 
which may need to rely on immutability of the underlying bits themselves.  This 
distinction would allow the programmer model to be modified to allow for lazy 
let.  

I think it is worth considering (after Swift 3) refining the programmer model 
to mean the value is always initialized before reading and is never written to 
after initialization.  This allows for implementation flexibility while 
preserving the semantics visible to users of the type.  In that respect it I 
believe it is similar in spirit to allowing internal references and CoW in the 
implementation of value semantic types.

It's also worth noting that lazy let is similar to a memoized computed let so 
it may help address that use case as well.  The difference is that with a 
computed let the compiler would need to guarantee the implementation is a pure 
function on immutable values.

One related area is weak properties.  I believe there is a strong case for 
something in between 'let' and 'private(set) var' here.  It may be desirable to 
guarantee that your code only initializes the weak property.  The only desired 
value change is when it is zeroed.  I'm not sure what this would look like, but 
maybe 'invisible(set) var' which guarantees that only the Swift runtime will 
modify the value after initialization.

> 
>>> On May 17, 2016, at 17:23, Leonardo Pessoa  wrote:
>>> 
>> 
>> David, I'm thinking about the side effects calling a computed property has 
>> and although I see some use cases for let properties I also see workarounds. 
>> For example, a lazy initialiser will solve the issue of running a certain 
>> code only once and caching its value. I also start to think that any case in 
>> this proposal will be solved by lazy initialisers thus rendering it 
>> unnecessary.
> 
> I’m not sure that an immutable lazy property and an immutable computed 
> property are mutually exclusive. I gave an example earlier, though it was 
> based on a misunderstanding of the proposal, but it seems relevant. Imagine 
> if you have a type that has two large immutable array properties, and a 
> computed property that combines them in some way. Do you really want to 
> double the size of your instance by storing that computed value, even after 
> it is no longer being referenced elsewhere? If each array were 512kb, you’d 
> be bloating the type to 2mb to store a value that may never be used again, 
> which is one of the main drawbacks of lazy properties; you could maybe work 
> around this with weak references or something, but that just adds more 
> complexity, whereas a computed property solves the problem by leaving it up 
> to whoever called it to store the value if it makes sense to do-so.
> 
> So yeah, I think that both features have their uses, and while computed “let” 
> properties may be relatively niche, the biggest benefit of them is really 
> that they self-advertise that they are unchanging, and that the compiler can 
> help to ensure this is the case, so it’s both a feature for API users to take 
> advantage of, and a defensive feature to help you to code your property.
> ___
> 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

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

[Haravikk via swift-evolution]

> On 18 May 2016, at 10:08, David Sweeris via swift-evolution 
>  wrote:
> 
> `lazy` properties can't be `let`. Personally, I disagree with this — their 
> initial mutation is transparent, and it's conceptually perfectly valid to 
> have a value that's, say, too expensive to calculate during every instance's 
> init and whose value never changes once calculated — but there may well be 
> Very Good Reasons for needing them to be `var`.

You can kind of do this already by adding private(set) to a lazy property, but 
yeah, the ability to define it as let would be more concise, work within the 
same type/file and possibly be more intuitive as well. Really it’s just an 
indicator to the compiler that a value shouldn’t be mutated so it can stop you, 
though there are some optimisations that can be done as well, many of these may 
not apply to lazy properties due to the way that they work.

> On May 17, 2016, at 17:23, Leonardo Pessoa  > wrote:
> 
> David, I'm thinking about the side effects calling a computed property has 
> and although I see some use cases for let properties I also see workarounds. 
> For example, a lazy initialiser will solve the issue of running a certain 
> code only once and caching its value. I also start to think that any case in 
> this proposal will be solved by lazy initialisers thus rendering it 
> unnecessary.

I’m not sure that an immutable lazy property and an immutable computed property 
are mutually exclusive. I gave an example earlier, though it was based on a 
misunderstanding of the proposal, but it seems relevant. Imagine if you have a 
type that has two large immutable array properties, and a computed property 
that combines them in some way. Do you really want to double the size of your 
instance by storing that computed value, even after it is no longer being 
referenced elsewhere? If each array were 512kb, you’d be bloating the type to 
2mb to store a value that may never be used again, which is one of the main 
drawbacks of lazy properties; you could maybe work around this with weak 
references or something, but that just adds more complexity, whereas a computed 
property solves the problem by leaving it up to whoever called it to store the 
value if it makes sense to do-so.

So yeah, I think that both features have their uses, and while computed “let” 
properties may be relatively niche, the biggest benefit of them is really that 
they self-advertise that they are unchanging, and that the compiler can help to 
ensure this is the case, so it’s both a feature for API users to take advantage 
of, and a defensive feature to help you to code your property.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

`lazy` properties can't be `let`. Personally, I disagree with this — their 
initial mutation is transparent, and it's conceptually perfectly valid to have 
a value that's, say, too expensive to calculate during every instance's init 
and whose value never changes once calculated — but there may well be Very Good 
Reasons for needing them to be `var`.

- Dave Sweeris

> On May 17, 2016, at 17:23, Leonardo Pessoa  wrote:
> 
> David, I'm thinking about the side effects calling a computed property has 
> and although I see some use cases for let properties I also see workarounds. 
> For example, a lazy initialiser will solve the issue of running a certain 
> code only once and caching its value. I also start to think that any case in 
> this proposal will be solved by lazy initialisers thus rendering it 
> unnecessary.
> 
> 
>> On 17 May 2016 at 17:50, David Sweeris  wrote:
>> You can't, if you're extending a pre-existing type.
>> 
>> I'd think that it might be possible to do some caching if the compiler knows 
>> that a computed property is constant, but maybe it doesn't work that way.
>> 
>> - Dave Sweeris
>> 
>>> On May 17, 2016, at 14:40, Leonardo Pessoa via swift-evolution 
>>>  wrote:
>>> 
>>> If the value of the property is a constant, shouldn't you just declare it 
>>> as one? If you have any sort of computation in it, even concatenating two 
>>> constant strings, can you really say this is a constant? And you would also 
>>> be overloading the compiler into trying to check for every property you use 
>>> let if the overall computation is constant or not. IMO, let isn't really 
>>> the most appropriate keyword to use for properties.
>>> 
>>> - Leonardo
>>> 
 On 13 May 2016 at 04:44, Andru Felipe Zuniga via swift-evolution 
  wrote:
 It would be useful for clarification of a computed property being constant 
 in extensions. For example:
 
 extension SKSpriteNode {
 static let type: String {
 return “Sprite”
 }
 }
 
 Andru
 
 
 
 ___
 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

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

[Leonardo Pessoa via swift-evolution]

David, I'm thinking about the side effects calling a computed property has
and although I see some use cases for let properties I also see
workarounds. For example, a lazy initialiser will solve the issue of
running a certain code only once and caching its value. I also start to
think that any case in this proposal will be solved by lazy initialisers
thus rendering it unnecessary.


On 17 May 2016 at 17:50, David Sweeris  wrote:

> You can't, if you're extending a pre-existing type.
>
> I'd think that it might be possible to do some caching if the compiler
> knows that a computed property is constant, but maybe it doesn't work that
> way.
>
> - Dave Sweeris
>
> On May 17, 2016, at 14:40, Leonardo Pessoa via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If the value of the property is a constant, shouldn't you just declare it
> as one? If you have any sort of computation in it, even concatenating two
> constant strings, can you really say this is a constant? And you would also
> be overloading the compiler into trying to check for every property you use
> let if the overall computation is constant or not. IMO, let isn't really
> the most appropriate keyword to use for properties.
>
> - Leonardo
>
> On 13 May 2016 at 04:44, Andru Felipe Zuniga via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> It would be useful for clarification of a computed property being
>> constant in extensions. For example:
>>
>> extension SKSpriteNode {
>> static let type: String {
>> return “Sprite”
>> }
>> }
>>
>> Andru
>>
>>
>>
>> ___
>> 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

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

[Leonardo Pessoa via swift-evolution]

If the value of the property is a constant, shouldn't you just declare it
as one? If you have any sort of computation in it, even concatenating two
constant strings, can you really say this is a constant? And you would also
be overloading the compiler into trying to check for every property you use
let if the overall computation is constant or not. IMO, let isn't really
the most appropriate keyword to use for properties.

- Leonardo

On 13 May 2016 at 04:44, Andru Felipe Zuniga via swift-evolution <
swift-evolution@swift.org> wrote:

> It would be useful for clarification of a computed property being constant
> in extensions. For example:
>
> extension SKSpriteNode {
> static let type: String {
> return “Sprite”
> }
> }
>
> Andru
>
>
>
> ___
> 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

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

[Andru Felipe Zuniga via swift-evolution]

It would be useful for clarification of a computed property being constant in 
extensions. For example:

extension SKSpriteNode {
static let type: String {
return “Sprite”
}
}

Andru



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andru Felipe Zuniga via swift-evolution]

It would be useful for clarification of a computed property being constant in 
extensions. For example:

extension SKSpriteNode {
static let type: String {
return “Sprite”
}
}

Andru



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 11 May 2016, at 21:04, Chris Lattner  wrote:
> 
> On May 11, 2016, at 11:31 AM, Joe Groff via swift-evolution 
>  wrote:
>>>   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.
>> 
>> Being constant doesn't need to imply "precomputed". I would expect a 
>> computed 'let' to still be computed on-demand. 'let' is more important as an 
>> API contract; you're guaranteeing to the user that an API won't produce 
>> different values if called on the same object at different times.
> 
> Right.  “let” means “always has the same value”, a get-only property means 
> “can not be set” (which is less restrictive).  Computed or not isn’t the 
> issue here.

Ah, thanks both of you, I misunderstood then.

Hmm, in that case though, other than the simple case given in the original 
message, it seems like this might be non-trivial to check, as you’d need to 
trace every method that could be used within the computed property to ensure 
that no vars are ever accessed.

I proposed a while ago the idea of having the compiler determine whether a 
method is mutating automatically, as this could do various useful things like 
issue a warning if a mutating method that doesn’t change anything and similar 
cases, but it was dismissed at the time due to the complexity of adding such 
checking. This seems like it might be similar in principle; it seems very 
reasonable in a self-contained method that doesn’t rely on any others, but the 
rest of the time it’s hard to check.

I suppose it could be done for these kinds of self-contained computed 
properties initially though?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

On May 11, 2016, at 11:31 AM, Joe Groff via swift-evolution 
 wrote:
>>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.
> 
> Being constant doesn't need to imply "precomputed". I would expect a computed 
> 'let' to still be computed on-demand. 'let' is more important as an API 
> contract; you're guaranteeing to the user that an API won't produce different 
> values if called on the same object at different times.

Right.  “let” means “always has the same value”, a get-only property means “can 
not be set” (which is less restrictive).  Computed or not isn’t the issue here.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On May 11, 2016, at 11:02 AM, Haravikk  wrote:
> 
> 
>> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>>  wrote:
>>> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
 On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
  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.

Being constant doesn't need to imply "precomputed". I would expect a computed 
'let' to still be computed on-demand. 'let' is more important as an API 
contract; you're guaranteeing to the user that an API won't produce different 
values if called on the same object at different times.

-Joe

> 
> 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.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 1:02 PM, Haravikk  wrote:
> 
> 
>>> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>>>  wrote:
 On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
  wrote:
 On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
  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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>  wrote:
>> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>>>  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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alexander Momchilov via swift-evolution]

Yeah, there will need to be a facility to annotating function purity

On Wed, May 11, 2016 at 1:00 PM, Joe Groff  wrote:

>
> > On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > 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.
>
> 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@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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>>  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 
>>>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>  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 
>>  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

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

[Rod Brown via swift-evolution]

I believe the reason behind this comes down to the fact that computed values 
generally won't be used in this way - thus the "computed".

var itself isn't a promise that a value is mutable, so much as 'let' is a 
promise of immutability. If we allowed this, then the compiler must check that 
each element of the return value is static and will not change, and in that 
case, why would you not just store the computer value in a true let to begin 
with, to avoid doing the work over again on each access?

It seems a somewhat rare and complicated case for the compiler, for little if 
any benefit.

-Rod

> On 11 May 2016, at 11:25 PM, Alexander Momchilov via swift-evolution 
>  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

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

[Sean Heber via swift-evolution]

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”.

l8r
Sean


> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution 
>  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