Shared resource extractor (`Res`) should allow non-optional resources

[dfunckt]

Using this example from docs:

fn multiple_resources(conn: Res<MyConnection>, config: Res<MyConfig>) {
    // a reference to the resources configured in the Worker below
    // can be access within the Job handler
}

Accessing conn returns an Option<MyConnection> which forces the user to unsafely unwrap if they know it can't be nil, which is unnecessary, unnatural and tedious, but most importantly fails to capture user intent with types.

If the user configures the system for Res<T>, then they should get T back. If T can indeed be nil, then providing Res<Option<T>> should do the trick.

[pipex]

This used to be that way, but the problem is that it required to panic if the resource didn’t exist (see the pr below). I agree it’s unintuitive that conn is an Option instead of the actual type. I’m not sure how to resolve it though

#44

[dfunckt]

… the problem is that it required to panic if the resource didn’t exist

I think that is the correct thing to do, because it”s a programmer error. The expectation is the value isn’t nil, so if it is we should panic. If the user’s expectation is the value can be nil, then it should be defined as Option T.

[pipex]

The thing is that the expansion of the extractors happens at planning, meaning that testing the generated plans would not be possible without having initialized the resources in advance. I would prefer to rename the extractor to OptRes<T> (or OptionRes) which makes it more evident that the resource is optional