4 ms·
IMHO, types for function parameters depends on the use case. If you have a function in a standard library, types are obviously helpful, albeit it can be convol
by olau 6y ago
IMHO, types for function parameters depends on the use case.
If you have a function in a standard library, types are obviously helpful, albeit it can be convoluted if they are templated.
On the other end of the scale, if you have a little helper function used to reduce duplication/increase readability in another function, explicit typing easily becomes busywork. This is where duck typing/templates shines.
I once sent a suggestion to the C++ committee people that they allowed easy templating of function parameters (something like "auto foo(auto bar)"), but I don't think people who are not used to duck typing appreciate how much it helps in the grunt work inside modules. At least, I didn't myself.
- Chris_Newton 6y agoI quite like the Haskell culture for this one: you specify the type signatures explicitly for your top-level functions, but you don’t usually specify them for nested functions. Put another way, anything with an interface you might need to understand somewhere else should be explicit, but anything only used very locally doesn’t need to be.
- pierrebai 6y agoWell, you'll be happy to know that C++ pretty much allows that, but not for templates. You can use auto in parameters if the calling context allows inference, for example when writing lambda. Similarly, you can use auto as a return type if the function implementation is immediately given and the compiler with infer the return type. The new starship operator (<=>) typical usage is pretty much declaring it with an auto return type and "= default" implementation.