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

[Haravikk]

> On 18 May 2016, at 10:08, David Sweeris via swift-evolution <swift-evolution at swift.org> 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 <me at lmpessoa.com <mailto:me at lmpessoa.com>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/2957df84/attachment.html>