spell out overload resolution

[pseyfert]

(triggered by this SO question)

I have noticed that while I was successful using cppinsights to look up what overload resolution a compiler picks on free standing functions example this does only work when implicit casts are involved. In a minimalized version of the above SO question here I see no cast that turns 0 to double*.
Artificially adding local variables (attempt) doesn't help spelling out the overload resolution either.

Long story short, I think it would be nice to see which overload resolution the compiler picked.

I see github detects my draft is similar to #249. I'm not sure how a printout could look. If I as a code author wanted to be explicit about which overload I want to pick, I'd probably add a comment of the intended signature

class H
{
  public: 
  H(const char *, int, double, double);
  H(const char *, int, double *);
  ~H();
};

H foo()
{
  // H(const char*, int, double*)
  return H{"hai", 4, 0};
}

though that might be messy once composed function calls are involved f(g(h(x))).
Matching how I used cppinsights so far for overload resolution, the following might also be usable

return H{static_cast<const char *>("hai"), static_cast<int>(4), static_cast<double *>(0)};

[andreasfertig]

Hello @pseyfert,

thank you for bringing this up, again. Your specific example actually revealed an issue in C++ Insights. There is a function IsMatchingCast which acts like a filter for casts. In the current version is filters CK_NullToPointer and CK_ArrayToPointerDecay. Both are responsible that your approach does not work. With your example as an rational, I consider this behavior a enhancement. My idea is to guard it with the existing --show-all-implicit-casts switch. That way it is less noise. The result, with the switch turned on, would then be this:

H foo()
{
  return H{static_cast<const char *>("hai"), 4, static_cast<double *>(0)};
}

This matches your version, just that the int is already an int, so no cast there.

I also see a value in adding the explicit chosen overload signature. However, known that it is in fact an overloaded call and where to place the signature is hard. That's why I prefer the option of showing more casts. Which makes it also more insightful and correct.

If this is what would help you, I'm ready to push the fix.

Andreas

[pseyfert]

Hi Andreas,

your suggestion and reasoning sound good to me.

Thanks,
Paul