DIP 88: Simple form of named parameters

Mathias Lang via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 23 08:35:33 PST 2016


2016-01-23 15:19 GMT+01:00 Jacob Carlborg via Digitalmars-d <
digitalmars-d at puremagic.com>:

> This is mostly to prevent ugly hacks like Flag [1].
>
> http://wiki.dlang.org/DIP88
>
> [1] https://dlang.org/phobos/std_typecons.html#.Flag
>
> --
> /Jacob Carlborg
>


About the rationale:
> Supporting named parameters directly in the language prevents the need to
add workarounds with weird looking syntax like Flag

That's going the opposite way of the current trend, which is shift as much
feature to library as possible.

> When interfacing with Objective-C it might be desirable to have a method
calling syntax which resembles the syntax used in Objective-C and Swift.

Implementing cosmetic features from a language because it appeals to its
user doesn't sound that useful to me.

The `createReq` example is a bit artificial, as you would usually replace
it with a struct.

About the design:
As mentioned earlier, forcing users to say which arguments can be named and
which cannot seems like an unnecessary limit. We'll just end up with
everyone using ':' after parameter names (which is very weird looking IMO)
in order to be able to use that syntax at the call site, if necessary.
Also, bear in mind that a lot of code one will use is not under one's
direct control. So if we want to use named parameter with a framework which
doesn't define this syntax, you cannot.
Since changing the order of parameter is not allowed, it sounds better to
just allow this syntax at the call site.
Also, one point which was not covered, should the compiler enforce that the
name used matches ? E.g. if I use `heigh` instead of `height`, should the
compiler tell me "change name `heigh` to `height`" ?

Overall, I'm not found of it. It looks like a lot of complication for
little to no benefit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160123/af979d97/attachment-0001.html>


More information about the Digitalmars-d mailing list