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

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jun 6 23:20:33 UTC 2019


On Thu, Jun 06, 2019 at 12:31:14PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/15/19 7:56 AM, Mike Parker wrote:
> > This is the feedback thread for the first round of Community Review for
> > DIP 1019, "Named Arguments Lite":
> > 
> > https://github.com/dlang/DIPs/blob/23ef47a94e0fdd5ddc4b2f6b2f4dcfd3c1f43aa6/DIPs/DIP1019.md
[...]
> * "Named arguments proposed by this DIP have no effect on the ordering
> of arguments in function calls." Related work will in all likelihood
> reveal that reordering arguments in large argument lists is a key
> advantage of named arguments. Not availing ourselves of that advantage
> is a serious issue that weakens the proposal. It must explain why it
> is not possible to allow reordering of arguments (or better yet work
> out the mechanics to allow it).
> 
> * "Named arguments proposed by this DIP do not allow default
> parameters to be skipped." Not sure what "skipped" means in context; I
> assume it means some defaulted arguments would be left unspecified and
> other following them would be specified with non-default values. My
> understanding is that this is another key advantage of named arguments
> in related work - typically complex functions with large argument
> lists like CreateWindow, CreateArchive etc.  would have many arguments
> defaulted to reasonable values, which then the caller can pick and
> choose which to customize. I assume a large part of what makes Python
> APIs so friendly is this ability. The DIP should explain why this is
> not desirable or achievable for the D language (or again better yet
> make it just work).
[...]

Yeah, these 2 points are also what greatly weakens this DIP, IMO,
because they could be construed to be the raison d'etre of named
arguments in the first place.  Not having them makes one wonder what's
the point of this DIP in the first place.  As Amaury said in his DConf
lightning talk, we don't want 95% features (or in this case, more like
50% features -- halfway there but missing major benefits of having named
arguments in the first place). We want 100% features that provide core
benefits, without being crippled in some way that makes them useless in
non-trivial cases.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth


More information about the Digitalmars-d mailing list