> On 18 May 2016, at 10:08, David Sweeris via swift-evolution
> <swift-evolution@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 <m...@lmpessoa.com
> <mailto:m...@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
