[masklinn]

> 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.

[fixermark]

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.

[masklinn]

> 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

[1] in an RFC 2119 sense

[f2f]

yes, it is clearer the Go way. things are up-front and obvious, easier to document, and less error-prone.

although your contribution in snark is much appreciated, you're incorrect.

[masklinn]

> yes, it is clearer the Go way.

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.