return type will be needed. Sorting by type might be useful then.

But if parameters are different then sorting by parameter list will make subsequent sorting by return type pointless.

Yes, it would be one or the other, the question would be which is most useful, or maybe an option (as a great man once famously said, "if given a choice, take both" 😁)

not typically what the user is looking for as the first criteria.

The first criteria is scope, we agree on that, but (at least for me) as I said above, the second criteria used in selecting an overload is what the function returns, and that tells me what the parameters I need to supply are. If I already know the parameters (which would need to be the case if I am selecting an overload based on them) then I don't really need the calltip.

But I can see that others may approach it as "I have these parameters, what overload is available" which is nearer to your workflow. This is likely common is a "programming for side effects" paradigm rather than a "functional programming for return value" paradigm.

But there are no studies that I know of that measure how common each approach is, and which is more efficient, or even if it changes as programmers become more experienced with a language with overloads. I would be really interested if it was out there.

Programmers all work in different ways, and no one approach is "right", so its not appropriate for either of us to say it must be one way or the other. In the absence of a design document that records why, all a prior choice to code one of the two options and not the other says is that is the way that person codes, and they either didn't even think of the other option, or didn't have time (the most likely).

What would be really useful would be for the options to be narrowed as parameters are typed, but that isn't possible with the current ctags/Geany model.

Of course we don't need to agree, the benefit of moving the return type to following is worth it, even if the sorting order is kept as is, and this discussion can go on elsewhere.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.