@yf225 merged this pull request in 801b6cd.

why do it this way instead of optional<Tensor>? Which is our plan for user-facing APIs that may take None, consistent with all our other types that take None.

@gchanan I feel that I need to make this consistent with how we represent a nullable Tensor within a C++ module, and I think there are two issues with using optional<Tensor> as nullable Tensor within a module:

1. If a user implements their own custom C++ module that has both nullable Tensors (e.g. torch::nn::Linear has nullable Tensor) and non-nullable Tensors, there will be two types of Tensors in their module (Tensor and optional<Tensor>), which I feel that it's not great from API simplicity point of view.
2. Custom autograd functions won't be able to use variable_list to represent inputs / outputs anymore (because some of those Tensors can be null). To address this we can add an optional_variable_list type, but I am a bit unsure if there is any other obstacle to this. cc. @ezyang

1. Idk that seems good. It says exactly what the state is. It's much clearer than what an "undefined tensor" means.
2. Yah, that's a good point. I don't know if there will be a noticeable performance difference in using optionals in those lists.