`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 <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.
>
>
>> On 17 May 2016 at 17:50, David Sweeris <daveswee...@mac.com> 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
