1) The forced inclusion of the package specifier on the type, rather than being able to directly reference the type via an import alias or something. You can alias the package name, but that's not a great general solution.
2) The forced inclusion of the type name at all. What, exactly, would be the type inference challenge if you were allowed to do something like this?
I understand, if the parameter in the signature were an interface, this would not work. But its not; its a struct. It feels to me like this kind of inference should be allowed when a parameter is a struct, but maybe I'm missing some subtle corner case where it would not work.
3) All the context stuff; both as a function parameter, and the words "WithContext". I hate this. To be clear; Context is awesome. Every function which has the possibility of making network calls should accept a context. And that's the problem; modern Go libraries liter it everywhere, adding "WithContext" mirrors of existing functions to maintain backcompat. Context really should be "contextual"; omnipresent, overrideable, and only getting in the way when its needed. 95% of functions which interface with a context accept the context and pass the context; they're middlemen. They shouldn't have to even care about the context. Something like:
In other words, available via magic global functions. I'm sure there's some reason why this wouldn't work, or would have unintentional negative consequences, but I illustrate it only for the point that there are ways to accomplish this goal that are (probably) cleaner than making it a function parameter.
In reality, its a small benefit to readability. You gain parameter names, which is very nice, but you end up with huge function call lines.
With the main sources of pollution here being:1) The forced inclusion of the package specifier on the type, rather than being able to directly reference the type via an import alias or something. You can alias the package name, but that's not a great general solution.
2) The forced inclusion of the type name at all. What, exactly, would be the type inference challenge if you were allowed to do something like this?
I understand, if the parameter in the signature were an interface, this would not work. But its not; its a struct. It feels to me like this kind of inference should be allowed when a parameter is a struct, but maybe I'm missing some subtle corner case where it would not work.3) All the context stuff; both as a function parameter, and the words "WithContext". I hate this. To be clear; Context is awesome. Every function which has the possibility of making network calls should accept a context. And that's the problem; modern Go libraries liter it everywhere, adding "WithContext" mirrors of existing functions to maintain backcompat. Context really should be "contextual"; omnipresent, overrideable, and only getting in the way when its needed. 95% of functions which interface with a context accept the context and pass the context; they're middlemen. They shouldn't have to even care about the context. Something like:
In other words, available via magic global functions. I'm sure there's some reason why this wouldn't work, or would have unintentional negative consequences, but I illustrate it only for the point that there are ways to accomplish this goal that are (probably) cleaner than making it a function parameter.