Dion likes named

I have always liked named parameters, as I have seen many bugs due to methods
such as: doFoo(String acct1, String acct2). Here we have no way to know if
someone is passing in the right info (other than via Unit tests).

Named parameters are indeed attractive, but they come at a price.

First of all, method parameters become part of the signature of your method,
which means you can’t modify them without breaking your users.  It might
sound like a minor annoyance but my experience tells me that the least you
expose in a public API, thee asier your life will be.

But the best lesson about named parameters comes from C++, again.

Named parameters almost made it into C++.  The proposal had been
reviewed several times by the Committee and there was a universal agreement on
their good qualities:  easy to explain, easy to implement, not representing
any major backward compatibilities issue, etc…

Bjarne was just a little bit concerned about the extra verbosity in the
source, which was going to make it harder to search source files, but he agreed
that his objection was not strong enough to decline this new feature (we can
also notice once again how pragmatic he is.  It’s also interesting to point
out that this kind of concern is moot now that IDE’s provide us with semantic

And then, a few days before the proposal was formally accepted, one of the
group experts sent an email to everyone saying "We don’t need named parameters,
we already have them".  And then he proceeded to demonstrate his point by
turning the working example (in Java syntax for readability):

Window w = new Window(x:0, y:0, color:blue)


Window w = new Window().x(0).y(0).color(blue);