Add a way to force-initialize a System.Lazy

[GSPP]

Lazy should have a way to make it compute the value on demand. This could be as simple as this:

    void ForceValue()
    {
      var dummy = Value;
    }

This is useful if Lazy is used as a cache and you want to pre-initialize that cache. That pre-initialization could be done in the background by Task.Run(() => myLazy.ForceValue()). I'm sure a ForceValue is handy in other situations as well. It does not clutter the class much and is trivial to implement.

[jnm2]

I do _ = lazy.Value;. Is there anything wrong with just discarding the return value?

(Also, changing the syntax from _ = lazy.Value; to something you prefer like lazy.CreateValue(); is a great use case for an extension method.)

[Clockwork-Muse]

...I have to ask, if you're force-initializing a Lazy, is it even, really, lazy anymore?

Once you start doing things like Task.Run(() => myLazy.ForceValue()), why not just do the computation in the task and await it wherever? The task is going to cache the result, and not recompute it.

Note that for the pre-initialization to be worth it, you have to either force the Lazy to be threadsafe (and thus cause the Value call to block/wait), or be pretty sure that that initialization is going to be finished before the first real call (or it throws out the result, meaning the pre-initialization was wasted).

[MarcoRossignoli]

...I have to ask, if you're force-initializing a Lazy, is it even, really, lazy anymore?

Also to me it's strange use lazy as "cache" system...i think that Lazy is useful to avoid "unuseful" allocation, preload seems opposite than lazyness. But maybe with complete "scenario" i could understand well the idea.

[GSPP]

I made this feature request because I recalled that I needed it. Indeed, I have my own Lazy implementation because System.Lazy stores exceptions which makes it extremely dangerous for long-running apps.

One scenario might be a lazy initialized cache but you want the cache to be pre-initialized in the background but only after a few seconds have passed in order to not slow down the start of the application. Here, we cannot just use a Task.Run because that would start running immediately.

I have now checked where I used this feature... It was in just two fairly esoteric scenarios that are not worth posting here.

So I understand the interjection that this might not be very useful. Feel free to close this if the team decides against having this feature!

[Clockwork-Muse]

@GSPP -
The documentation for Lazy explicitly mentions that:

If there is a potential for a recoverable failure, we recommend that you build the retry logic into the initialization routine (in this case, the factory method), just as you would if you weren’t using lazy initialization.

...the exception caching is considered a feature.

As for worries about Task.Run starting immediately... trivially that can be changed to a Task.Delay(timespan).ContinueWith(...), but perhaps more interestingly could be changed to taskCompletionSource.Task.ContinueWith(...), which makes the launching controllable.

[GSPP]

Retries cannot really be placed inside because retrying might take extremely long (or never complete). All threads consuming the lazy would be held up indefinitely. In a web app that quickly consumes the entire thread pool. With an async lazy the same issue exists. Unbounded resources will be consumed and incoming requests will be delayed indefinitely.

Rather, failures must propagate out of the lazy. Yet the lazy must be restartable.

Regarding the delay init scenario, Task.Delay(timespan).ContinueWith(...) does not work because initialization must start immediately when the lazy is needed or based on a delay.

[Clockwork-Muse]

Rather, failures must propagate out of the lazy. Yet the lazy must be restartable.

This sounds like a separate api-suggesstion, perhaps propose that too?

[GSPP]

You mean a way to reset the lazy? I personally really needed that for caching scenarios and it was an important reason to create my own lazy. Implementing that could be difficult and force worse performance. Now, the lazy transitions only forward in time. With resetting it can transition back into old states (ABA problem). That makes low-synchronization code problematic to achieve.

[tsvx]

I made this feature request because I recalled that I needed it. Indeed, I have my own Lazy implementation because System.Lazy stores exceptions which makes it extremely dangerous for long-running apps.

@GSPP, could you give a link to your implementation, please?

[Clockwork-Muse]

@tsvx - I've become less convinced that this is a necessary new feature, especially since the reason you're quoting is a red herring.

Essentially, Lazy's position is that the resource should be initialized once (let's ignore threading issues, here), and that either the initialization succeeded, or it failed, just like normal object instance initialization. The only difference is that the initialization was delayed until actually needed. It's not really meant to be a caching system (there are other types/libraries for that). It's also not really intended to be an off-thread initialization system (use async for that).

[GrabYourPitchforks]

It has been a while and this issue hasn't had any recent activity. Is there any reason the suggestion at https://github.com/dotnet/corefx/issues/32551#issuecomment-425735834 (use a discard) isn't satisfactory?

[GSPP]

I have laid down my case for this feature, and the discussion was pretty exhaustive. If the team is not convinced at this point, I think it's time to let this go 😄

[stephentoub]

If the team is not convinced at this point, I think it's time to let this go

Thanks for the suggestion and discussion. I'm going to close it.