DIP 88: Simple form of named parameters
Mint via Digitalmars-d
digitalmars-d at puremagic.com
Sat Jan 23 07:49:20 PST 2016
On Saturday, 23 January 2016 at 15:34:00 UTC, tcak wrote:
> On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg
> wrote:
>> This is mostly to prevent ugly hacks like Flag [1].
>>
>> http://wiki.dlang.org/DIP88
>>
>> [1] https://dlang.org/phobos/std_typecons.html#.Flag
>
> Without making things any complex, the simplest thought of mine
> is:
>
> Keep everything same. But allow caller to put name of parameter
> front its value wherever desired.
>
> Let's say,
>
> Rect createRect(int x, int y, int width, int height);
>
> So you could call it like:
>
> createRect( 10, 20, width: 200, height: 500 );
I concur, the additional syntax for declaring functions that take
named parameters is entirely extraneous. For the most part, it
just complicates implementing the feature by adding additional
considerations in regards to how tuples would represent the set
of types,
ie. ParameterTypeTuple!foo where foo(int a:, int b:)
For the most part, I wouldn't be opposed to all functions
accepting this syntax, although there still is the consideration
of how the call is handled. Notably, is the named-parameter an
expression of it's own that is only valid (or only meaningful) in
the context of a function or constructor call? Otherwise, we
still have the problem of how named-parameters are stored in
alias sequences.
Also as a minor note, I don't really understand the case for
parameter reordering. Typically speaking, the use case for named
parameters is to allow calling a function (or constructing and
object) without knowledge or concerns for what order the
parameters are expected in. Otherwise, the syntax is largely just
irrelevant. It simply adds additional cruft without any gain from
doing so.
More information about the Digitalmars-d
mailing list