DIP 1019--Named Arguments Lite--Community Review Round 2

[Piotr Duda]

niedz., 9 cze 2019 o 04:50 Jonathan Marler via Digitalmars-d
<digitalmars-d at puremagic.com> napisał(a):
>
> On Sunday, 9 June 2019 at 01:34:50 UTC, Paul Backus wrote:
> > On Saturday, 8 June 2019 at 18:05:43 UTC, Jonathan Marler wrote:
> >> I see value in allowing a caller to omit arguments that have
> >> default values, but what is the value in allowing the caller
> >> to reorder them?
> >
> > Without looking at the documentation, which of the following
> > calls would fail to compile if argument reordering was
> > forbidden?
> >
> > spawnProcess("/usr/bin/sort", stdout: outputFile, stdin:
> > inputFile);
> > spawnProcess("/usr/bin/sort", stdin: inputFile, stdout:
> > outputFile);
> >
> > From a usability perspective, it's completely insane for only
> > one of these to work.
>
> Of the top of my head stdin is first...but I don't think many
> people would know that.  It's just that I've written wrappers to
> spawnProcess so many times that it's ingrained in my head.  But I
> think whether or not I know is irrelevent to your point :)
>
> I believe that optimizing code for the reader should take
> priority over optimizing for the writer.  The antithetical
> example is the perl language...writing it can be terse and quick
> but reading it can make your head spin.
>
> I think your point is that when developers write code like this,
> having to put arguments in a particular order seems like an
> unnecessary burden.  I agree it's an extra burden on the writer,
> but enforcing the same order reduces the complexity of overload
> resolution and knowing how to map arguments to parameters,
> something which the "reader" needs to be able to do whenever they
> see a function call.
>
> Consider,
>
> foo(int a, int b, int c, int d, int e, int f);
>
> foo(1, 2, 3, 4, 5, 6); // a=1, b=2, c=3, d=4, e=5, f=6
>
> Now let's see it with some argument re-ordering:
>
> foo(6, c=1, e=2, 3, b=4, e=5, a=7);
>
> What's the values of a/b/c/d/e/f in this case? This may have made
> sense when it was written, but this is not beneficial for the
> reader.
>
> This gets worse when you introduce the concept of
> order-of-evaluation:
>
> int x = 0;
> foo(x++, c=x++, e=x++, x++, b=x++, e=x++, a=x++);
>
> Now what are the values of a/b/c/d/e/f?  Do you evaluate
> arguments in the order of the call, or the order of the function
> definition?
>
> These are the problems before you get into overloading.  Now add
> that into the mix:
>
> foo(float a, float b, float c, int   d, float e, float f);
> foo(float a, float b, float c, float d, float e, int f);
>
> foo(0, c=1, 2.0, 0.0, b=4, e=5, a=7);
>
> ...
>
> Keep in mind that I'm not saying that by enabling re-ordering
> we're going to start having a huge mass of unreadable code like
> this.  These examples are contrived to show you how re-ordering
> can make things confusing.  But when you enable powerful things
> like this, you are adding an extra burden on the reader every
> time they see a function call.  The more rules you add, the more
> unsure you make the reader and the more rules the reader has to
> remember and evaluate in order to understand the code.  Now
> whenever they see a function call with named arguments, they're
> going to have to go through a mental checklist of rules to be
> sure which overload is actually being called and which parameters
> are receiving which arguments.
>
> The benefit of allowing the writer to re-order arguments should
> be weighed against the burden of the reader to then understand it
> later when they do.

There is simple solution for this, don't allow positional arguments after named.