Have you tried inheriting from TensorIteratorBase? You can do that with structured_inherits: TensorIteratorBase.

It looks like right now, you don't use TensorIteratorBase at all in the meta functions of isneginf and isposinf. Two reasons that would be useful are:

• We want to make sure that the meta function does all of the type promotion / broadcasting / handles other meta-like edge cases. If you use TensorIterator in the actual impl() function but not the meta() function, there's a risk of forgetting to do some checking in the meta function that's normally handled by TensorIterator.
• (More long-term) We eventually want to make all TensorIterator ops structured and use TensorIteratorBase everywhere, instead of TensorIterator.

Let me know if you run into issues with that - we've had some instances of it being hard to directly use TensorIteratorBase, mostly because TensorIterator doesn't let you modify the output tensor before calling into it. I think you'll have to use .declare_static_dtype_and_device(kBool, self.device()) in the config to force TensorIterator to treat the output tensor as a bool.

cc @ysiraichi in case you uncovered any other issues - I think you started looking into porting a few binary comparison ops.

@bdhirsh it seems like the intention here was to avoid constructing the TensorIterator entirely in the case that we short circuit to fill_.

But I do agree that TI is better, because as currently written the meta function is wrong, as it doesn't preserve layout.

One point need to discuss is that, after considering similar operators (like torch.signbit) that require boolean casting output, I wrote unary_boolean_op for code reuse. I am not sure if that is appropriate or should I build TI directly in meta function?

hmm, one reason not to is that it looks like not all "unary boolean" ops follow this same set of config.

E.g. looking at the logical_not kernel - it's pretty similar, in that torch.logical_not(a) will return a boolean tensor, but it looks like it doesn't enforce that the out= tensor has to have boolean dtype. So you can't unconditionally use .declare_static_dtype_and_device(at::kBool, a.device()) - you only want to do it when the output is currently not defined (in the functional version of the op).

If you leave this as a TensorIterator API, can you change the name (maybe unary_force_boolean_op?), and leave a comment mentioning that this API should only be used when the output tensor must have boolean type?

It sounds very reasonable, thanks for such detailed explanation! Let me change the name and leave a comment to describe that.