Why does return require cast to double?

[alecjacobson]

I'm trying to understand a compiler error and I think it's related to this choice:

libigl-python-bindings/src/unproject_on_line.cpp

Line 72 in 6bf30bc

return std::make_tuple(double(t), npe::move(Z));

How come double(t) is needed here rather than just t ?

[alecjacobson]

changing to t gives this error

...unproject_on_line.out.cpp:350:1: error: return type 'tuple<double, [...]>'
      must match previous return type 'tuple<float, [...]>' when lambda expression has unspecified explicit return type
return callit_unproject_on_line<Map_uv, Matrix_uv, Scalar_uv,Map_m, Matrix_m, Scalar_m,Map_vp, Matrix_vp, Scalar_vp,Map_origin, Matrix_origin, ...
^

Not sure how to parse that.

[fwilliams]

Ah this is a gotcha in NPE:

Under the hood, NPE generates a templated function (in this case callit_unproject_on_line) with your code. It then generates a switch statement which calls this function with the appropriate types depending on what gets passed in to the python binding.

In the posted code, t has type npe_Scalar_uv which can be different depending on the type of uv. Thus, you end up with different return types for different template instantiations of callit_unproject_on_line which is not valid C++.

Note that npe::move handles this by casting your Eigen::Matrix types to PyObject* (or whatever pybind11's wrapper for this is) smartly (handing memory ownership and avoiding copies), so your return types always match with npe::move.

To return a single scalar, casting to the highest precision type seems like the reasonable thing to do here.

[alecjacobson]

Makes sense. Maybe to generate fewer templates t should just be defined to be double in the first place.

…

On Wed, Apr 20, 2022, 1:05 PM Francis Williams ***@***.***> wrote: Ah this is a gotcha in NPE: Under the hood, NPE generates a templated function (in this case callit_unproject_on_line) with your code. It then generates a switch statement which calls this function with the appropriate types depending on what gets passed in to the python binding. In the posted code, t has type npe_Scalar_uv which can be different depending on the type of uv. Thus, you end up with different return types for different template instantiations of callit_unproject_on_line which is not valid C++. Note that npe::move handles this by casting your Eigen::Matrix types to PyObject* (or whatever pybind11's wrapper for this is) smartly (handing memory ownership and avoiding copies), so your return types always match with npe::move. To return a single scalar, casting to the highest precision type seems like the reasonable thing to do here. — Reply to this email directly, view it on GitHub <#138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARDJGMSOLHD4FPXXBJ6ZS3VGA2OJANCNFSM5T2ICD7A> . You are receiving this because you authored the thread.Message ID: ***@***.***>