Add a separate trait for optional extractors

[jplatte]

Motivation

Closes #2298.

Solution

• Add OptionalFromRequest, OptionalFromRequestParts
  • Q: Should the trait items have different names from the ones in the non-optional traits?
• Implement for relevant types
• Deprecate OptionalFoo extractors
• Documentation
• Changelog

[jplatte]

@davidpdrsn Have you had time to take a look? The main changes are done, and I don't want to do the remaining docs / changelog writing and cleanup if it's not yet clear whether this will be merged.

[jplatte]

@mladedav @yanns both of you have been active with contributions recently. Would you be up for reviewing this? For context, see the linked issue.

[mladedav]

One thing that bugs me is that the optional variants use the same rejections so for example if someone uses the optional typed header there still is valid representation in the rejection. for the missing case.

That said the rejections are non exhaustive so they cannot handle explicitly everything so they may omit this one as well. It might just be confusing.

I will read it more thoroughly tomorrow or over the weekend, but it makes sense as a whole.

I want to think on other ways to make the option work but on a first sight this may be the best solution.

[mladedav]

The code looks good to me.

The drawback I see here is having two distinct traits so it might be harder for users to discover how to properly use Options. That said in hindsight, it might be better to force users to use Result instead of Option if they really mean to just discard any errors.

I am still unsure about whether it is better to use the same rejections for optional and normal extractors if the missing case is already handled in the normal rejection. I think we could use some kind of enum (probably very similar to Option) for extractors that have optional variants. But each extractor would have to define IntoResponse for its missing case.

I also wonder if we couldn't get away with just one FromRequestParts trait where the extracting method would return an enum with three cases like MyResult<T, T::Missing, T::Rejection>. Then we could maybe create the extractors with correct semantics without the need for multiple traits.

But if that's not possible or having the two traits is a better tradeoff than whatever issues that potential solution has, the implementation as is looks ok. I think we should just go over the implementations of FromRequest and FromRequstParts and add a few implementations for the optional conterparts.

[mladedav]

I think this should also be derived and usable.

[jplatte]

Why? When would it be None?

[mladedav]

I think this should be Infallible as missing is the only failure case.

And just to be sure, it seems to me like the only way MatchedPath would be missing is if it is accessed inside a fallback handler? If that's so, I think it would be better not to add this impl and have users just use Result if they want to guard against using it there.

[jplatte]

It could also be missing if you don't use Router at all, for example calling .into_service() on a handler and using the resulting handler as a standalone service.

Why would it be better to require users to use Result here in your opinion? I think both the Option and Result route are very rarely useful, but if you want to distinguish, or just be defensive against logic bugs affecting other parts of the system, the Option route seems more convenient.

[jplatte]

Damn, I didn't realize I failed to respond to most of the feedback here since asking for it. I definitely think having more specific rejection types would be better. I think it's something I skipped initially because it was just easier that way for the first prototype.

I'll try to make some time to back to this soon-ish.

[jplatte]

Suggestions for the docs would be very much welcome 😅

[jplatte]

Gentle ping regarding re-review, @mladedav

[mladedav]

Thanks for the ping and sorry for the wait.