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