On 14 Aug 2015, at 8:47 PM, Rick Mann <rm...@latencyzero.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
