[Pre-RFC] named arguments

language design
148

  1. The feature makes for more-verbose code, which in some cases helps clarify, but in some cases is equivalent to "noise", "boilerplate" or other complaints people have about excess verbosity in languages. Hopefully it is simple to see that the second declaration here is noisier:

     send_onions(amount:int, size:int)
 send_onions(pub amount:int, pub size:int)

    And that the second call here is noisier:

     send_onions(amount, size)
 send_onions(amount: amount, size: size)

  2. The feature (as-proposed) allows reordering of labeled arguments and optional use of labels on labeled arguments. This particular combination is hazardous because it means that given the declaration:

     fn launch_missiles(pub lon: float, pub lat: float)

    the two calls:

     launch_missiles(lat, lon)
 launch_missiles(lat: lat, lon: lon)

    mean different things, even though a reader might imagine they are the same call "with clarification", and an author might copy-paste-modify to switch between the two on a call-site-by-call-site basis, based on their own taste. This is a comprehension hazard that I've seen in the wild, in named-argument code in both Ocaml and Python.

I'm not wildly opposed to the feature or anything. I realize it can be done in tasteful ways (I happen to like the restrictions Swift puts on it). I do think that in even its most-restricted forms, it has a cognitive-load tax on basically every declaration and call site, which is .. a lot of places. It's not a thing users can overlook or learn later. It'll be in everyone's face, all the time. I question whether that's a good way to spend the user's mental energy.

Considering that despite its age as a potential feature, it is non-ubiquitous in languages (unlabeled-argument languages keep being produced, used, enjoyed), I think it is not a clear-cut win.

9 Likes