```c++ auto get_token(T my_arg) const -> const some_long_namespace::some_long_type<another_namespace::some_id, a_different_namespace::another_id>;
auto x = get_token( ``` The calltip shows the very long return type first, which gets in the way of reading the rest of the function signature. It should be shown in the same way the source function was written.
Yeah, without strategic typedefs or type aliases qualified names can get a "bit" long.
Sadly this won't help if the long return type is before the function name though.
There are no guidelines when to use pre/post types (in Bjarne & Herbs guidelines) so post types are mostly used when they depend on types deduced from parameters. In other words most returns are still in front of the name, so the same problem happens, but more often, and this won't fix the problem.
Be nice to find a universal solution though.
Multiline calltips?
This is how Vscode shows a random STL call I have open.
```cpp inline std::map<std::string_view, std::unique_ptr<Source>>::iterator std::map<std::string_view, std::unique_ptr<Source>>::find(const std::string_view &__x) ```
Be nice to find a universal solution though.
Well Geany could use *[scope::]func_name(params) -> return_type* format for C++ calltips. It should be familiar to any modern C++ developer and `->` is fairly intuitive anyway. It would be especially useful when there are overloads returning different types, otherwise clicking through the calltip arrows to find the one is awkward to read. Like that, overloads with different scope are immediately obvious. Looking for a scope and/or parameter overload is more common than looking for return type (and even if looking for the latter you can just look to the end of the calltip). Also the calltips are not even sorted by return type, so that alone is evidence the return type is not the salient info.
Aside: annoyingly, Scintilla doesn't seem to support selecting a calltip from a drop down list of overloads so you have to manually go through each one. Could probably be implemented outside Scintilla maybe.
Well Geany could use [scope::]func_name(params) -> return_type format for C++ calltips. It should be familiar to any modern C++ developer and -> is fairly intuitive anyway.
Agreed
It would be especially useful when there are overloads returning different types, otherwise clicking through the calltip arrows to find the right one is awkward to read. Like that, overloads with different scope are immediately obvious. Looking for a scope and/or parameter overload is more common than looking for return type (and even if looking for the latter you can just look to the end of the calltip).
Agree it is most common to select overloads based on scope.
Also the calltips are not even sorted by return type, so that alone is evidence the return type is not the salient info.
There are situations where the same function returns different types depending on parameter types (eg `std::map::insert()` returns either a `pair` or `iterator` or `void` or `insert_return_type` depending on parameter type) so selecting between calls in the _same scope_ based on "what do I want to get from this call", ie return type will be needed. Sorting by type might be useful then.
But your evidence argument is plain spurious, just because something is not done, its not evidence that it would not be useful, otherwise nothing would ever happen, Enrico would have said "Geany does not exist, so that is evidence its not needed, so I won't write it".
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.
But your evidence argument is plain spurious, just because something is not done, its not evidence that it would not be useful
I didn't say not useful, I said not salient, and I actually meant that it is not typically what the user is looking for as the first criteria. It is evidence, because someone did think about it when they wrote the code. You are welcome to dispute the quality of the evidence.
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" :grin:)
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.
github-comments@lists.geany.org