Why does _InputArray::convertTo(OutputArray dst, int rtype, ..) or cv::convertTo(..) not exist?

The classes Mat, UMat and cuda::GpuMat all have a convertTo(…) function with the same functionality.

From my point of view, for reasons of symmetry and for a smart handling of images in different representations (Mat, UMat and cuda::GpuMat) the function

void _InputArray::convertTo(OutputArray dst, int rtype, double gain = 1., double offset = 0.) const;

would be useful.

The function

void cv::convertTo(InputArray src, OutputArray dst, int rtype, double gain = 1., double offset = 0.);

would also do the trick to handle the different image representations with just one function signature.

In fact for the quite similar case of copyTo(…) both functions exist.

What is the reason for this asymmetry? And where is a good place to address this suggestion?

just out of couriosity,
do you have any use-cases, which are not covered from the current api ?

Well, I have a use-case, but I must admit, it is a bit special and at the moment I have no idea for a more general use-case.

However, you asked for it and so here it is:
In our company, we developed a scripting environment based on Qt-script quite similar to python. In this environment images are represented as a variant of Mat, UMat or GPUMat and we use a class based on cv::_InputArray as interface to all image processing functions available in the script language. For instance - thanks to the transparent api - the convertScaleAbs(..) functions is just implemented as

void ScriptObjectOpenCVCore::convertScaleAbs(ScriptObjectCvInputArray src, ScriptObjectCvOutputArray dst, double alpha, double beta)
{
  cv::convertScaleAbs(*src.inputArray_, *dst.outputArray_, alpha, beta);
}

or for copyTo(..)

void ScriptObjectOpenCVCore::copyTo(ScriptObjectCvInputArray src, ScriptObjectCvOutputArray dst, ScriptObjectCvInputArray mask)
{
  src.inputArray_->copyTo(*dst.outputArray_, *mask.inputArray_);
}

This works for all functions but not for convertTo(). Here we need a switch case for the different variant types.

Maybe someone else has a better idea for a less special use-case. However, my main point to implement the sugested functions is symmetry. From my point of view, the lack of the suggested functions is just a defect in the transparent api promoted in OpenCV.