Re: Referring to self in property initializer
Re: Referring to self in property initializer
- Subject: Re: Referring to self in property initializer
- From: Fritz Anderson <email@hidden>
- Date: Mon, 17 Aug 2015 10:39:01 -0500
On 14 Aug 2015, at 8:47 PM, Rick Mann <email@hidden> wrote:
>
> So, adding lazy lets it work with the closure (makes self available to the closure):
>
> lazy var backgroundSession : NSURLSession =
> {
...
>
> I really wish you could do lazy let foo = .... I don't see why the language can't support that.
I see your logic: `let` is a constant, guaranteed set before first access (you can write all the code you want between declaration and access, so long as all provable execution paths guarantee the constant is initialized). You can’t get the value of a `lazy` symbol without triggering the initializer and thus guaranteeing a value exists. So you might as well call it a `let`.
I don’t know enough about the constraints on the compiler or the design of the language that might make `lazy let` undesirable:
Must a `let` constant’s value be known (and inline-able) immediately _before_ the source requests the access (consequently triggering the initializer)? And not after the value returns to the code that requests it?
Is it fair to say that even if you can’t access the value _in Swift code_ without triggering, that the value of the symbol does not exist in memory until it is initialized, and the name for a symbol with a value that can change is `var`, not `let`?
Is it difficult for the compiler, or confusing to the user, to have `lazy let` be an exception to the requirement that all ivars (remember `let`s are notionally not variables at all) must be set before a call out of an `init`?
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden