The wording is not strictly correct:

• If p is not null, it calculates F-1(p)
• If p is null, it calculates F-1(F(bin_edges)) = bin_edges

Maybe someone is using this second variant (p=null) for something, so changing this would break backward compatibility.

What is exactly your use case / what you want to achieve?

If what you want is to have a new method to get F(x), then that method already exists, it is TH1::GetCumulative, so not sure if it's useful to add a new function name for this.

Or what bothers you is that it is a default argument?

Oh. Missed GetCumulative. The thing that probably bothers me is the description of GetQuantiles or rather what is the use case of GetQuantiles with p==nullptr. When you say "If p is null, it calculates F-1(F(bin_edges)) = bin_edges", the bin_edges are already known (if it really calculates them inside, that is quite surprising). The really new thing (although maybe not a product, but side-effect) is the p.

I understand that removing the default would break backward compatibility, so I am not advocating just removing the thing in the next release. It's just that if there is a default argument, normally it represents a frequent use case, so it brings attention while learning about a given method. Here it brings confusion (to me and to my student at least).

Given what you wrote and what I wrote, I no longer have a firm opinion on what should be done with it unfortunately...

he really new thing (although maybe not a product, but side-effect) is the p.

But p stays null. F(x) is stored to a temporary variable, p is not set to F(x).

(if it really calculates them inside, that is quite surprising)

It does. It's a technical workaround to have both paths to follow the same code.

It's just that if there is a default argument, normally it represents a frequent use case, so it brings attention while learning about a given method. Here it brings confusion (to me and to my student at least).

I agree with you.

So I would suggest to remove from your title "add new method to handle this case".
Making it non-default would force everyone to pass an argument. If one wants the old behavior, it will pass nullptr and get the bin edges as before, so no new extra method is needed.

Side note, the default value for p is there since 23y:
95d7d30

I missed that p stays null. You showed it in the comment to the other MR...

In this case I don't understand what was the idea 23 years ago. I can't imagine the use case for this.

I think the current title for the issue is good.

We need @lmoneta for clarifying this...