curious does .mode(options.mode()) work?

The problem here is that UpsampleOptions::mode_t and InterpolateOptions::mode_t differ by one variant member: torch::kArea (in Python "area"). According to the Python torch.nn.Upsample documentation, "area" is not an acceptable mode option, as "area" is commonly used as a decimation/downsampling mechanism. It happens to be passable because it is not checked in the module's __init__.

Would you like me to add torch::kArea as a variant member in Upsample::mode_t? This would make your suggestion possible. :)

Ah that makes sense, thanks for the catch! One thing that's a bit worrying to me is that I am not sure if the conversion from UpsampleOptions::mode_t to InterpolateOptions::mode_t is always well-defined :( Maybe we can create a temporary variable and use if-branching to set the value to be passed into F::interpolate explicitly :D

Note: The TORCH_ARG-macro carries the private: access modifier over to the next line so that any following non-TORCH_ARG declaration gets "secretly" privatized. In this case, it hides
typedef c10::variant<...> mode_t (and similarly other option variants such as the reduction_ts) from users.

I had to place the InterpolateOptions::mode_t type alias declaration before any TORCH_ARG to expose the type publicly. This allowed me to create a temporary InterpolateOptions::mode_t mode; and ergonomically make the necessary update based on your suggestion.

Just thought I'd mention it because it may be useful to let users have access to these types: modes, reductions, etc. :D. Otherwise, decltype seems to be the only way to get this type information. Let me know what you think! :)

Thanks so much for the catch! Yes I think we should establish the convention throughout the codebase that typedef c10::variant<...> mode_t should always happen in the first line of any Options that uses c10::variant (It is not enforced everywhere in the codebase right now, I opened a PR for PadOptions in #28760) :D