Default values mean optional arguments. Optional arguments mean functions with lots of arguments. Then you need to document what happens with each option. Not having that possibility enforces you to actually design an elegant API, instead of stuffing everything in a function and relying in optional arguments to hide the mess.
> Not having that possibility enforces you to actually design an elegant API
Yes, of course, the forced elegance of MarshalIndent next to Marshal — being able to indent in Marshal would be graceless, of CreateHeader alongside Create in case you wish to specify more than just the file name, of asn1.Unmarshal and its friend asn1.UnmarshalWithParams, so much more dignified than Unmarshal optionally taking params is it not?
You'd have to be blind not to see the refinement of DialHTTP to connect to an RPC server, unless you want to connect to a path which isn't / then DialHTTPPath has that undefinable quality of an excellent API, you definitely wouldn't want DialHTTP to just have a default path that would be tasteless.
And it's really quite obvious to have ToUpper and ToUpperSpecial, can you imagine how unpolished an optional case parameter to ToUpper would look?
Or Split taking an optional number of substrings? How gauche, lucky us the designers of the API were forced to add the soigné SplitN to which you can explicitly pass a negative number to get all substrings.
Really there are so many examples of the lack of optional parameters forcing the design of an outright dandyish API. Just look at WIN32, saved from the dreaded "lots of arguments" by C not having default parameters, not a function in there using that to hide the mess no sir, not in a million years would a language with default parameters have achieved the summit, the peak, the pinnacle of delight that are CreateWindowEx or RegQueryValueEx.
And naturally optional anything means you will build an inelegant API one day and have lost all chance to elegant API, which is why Go requires all structure fields to be explicitly filled.
shrug It'd be one more special case for the compiler to handle (and one more feature for my brain to hold onto when reasoning through code... "This is being called with two arguments, is that a typo or does this function take default arguments? Guess I'll have to go look up the function's declaration...").
I can see the alternate viewpoint but given that we can use structs and default fields to get the same effect I'm happy with the current solution.
> I can see the alternate viewpoint but given that we can use structs and default fields to get the same effect I'm happy with the current solution.
And that's completely fair, I routinely use languages both with and without optional parameters[0] and that's fine I'm not saying languages must[1] have optional parameters, or even that they should[1]. My comment only tries to humorously denote that the claim I quoted is pure lunacy.
> we can use structs and default fields
Don't forget the builder pattern which works pretty well to replace optional parameters (and keyword/named parameters), though it's less convenient on the implementer's side.
[0] whether in the "native" sense à la Python or C#, in the "overloaded method" sense à la C++ or Java or in the "well your question doesn't even make sense" à la Smalltalk
Hardly, but that's not the argument, I was replying to an assertion that not having default arguments enforces you to actually design an elegant API. It does no such thing. Contrary to the person I was replying to (and to you apparently) I would say that there are advantages to and issues with both options, but the claim I quoted and replied to is just plain insane.
> things are up-front and obvious, easier to document, and less error-prone.
Things are none of these, the exact same claim can be made about having optional parameters and against not having them.
I hear what you are saying, and functions can certainly get messy with too many arguments, default or otherwise, but if you are disciplined about the number of arguments a function takes then having this feature (default optional arguments) is a huge win for a language.
IIUC, the go-idiomatic way to do this if you find yourself wanting default arguments is to pass in a struct as one of the args to your function and have the default values of the fields in the struct mean "default" in the behavior of the function.
But in general, if you have a two-argument function and one of the arguments could be defaulted, just pass it. It's clearer at the call point what's happening then.
It's an extremely useful feature in Python, and makes for more elegant APIs.