DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-23 17:35, Mathias Lang via Digitalmars-d wrote:

> 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.

Yeah, I know. But I think this is worth adding and that Flag is hurting 
more than it's helping. Just because something is possible to do in the 
library doesn't mean it's a good idea.

There's been a lot of C++ related features which purely is about 
mangling. This could be handled in library code together with 
pragma(mangle). Yet these where added anyway. Yeah, I know everyone will 
complain that's not the same thing.

>  > 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.

This was not part of my initial idea. It was added as a bonus. I can 
remove it from the rational if it's preferred.

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

Yes.

> 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.

I think the DIP clearly states why this is the case. There have been 
several proposals for named parameters before, they have all been shot 
down because of this (and the ordering of the parameters). I'm not out 
to create the most ideal and perfect proposal. I'm trying to provide a 
proposal that has a chance of being accepted.

> 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`" ?

Hmm. That's kind of interesting. My idea was that the compiler should 
enforce that. But if the names don't need to match the only thing that 
is necessary is a syntax for adding names at the call site. The syntax 
for declaring the named parameters would not be required.

> Overall, I'm not found of it. It looks like a lot of complication for
> little to no benefit.

How is it complicated? I think it's very simple. The feature could be 
summarized with this example:

Rect createRect(int x:, int y:, int width:, int height:);
createRect(x: 0, y: 0, width: 200, height: 200);

Just because I described how the feature work in detail doesn't mean 
it's complicated.

-- 
/Jacob Carlborg