In the near future, I'll be prepping Mike Franklin's DIP, "Deprecation and removal of implicit integer and character literal conversion to bool" for community review. We need some more eyes on it for Draft Review first. For those of you whore are interested:

https://github.com/dlang/DIPs/pull/99

We also have a new DIP in the queue that is ready for Draft Review" "Named arguments lite". It won't be in line for community review until I've gone back through the queue from the beginning to see if the authors of older DIPs are ready to move forward, but feedback is welcome now:

https://github.com/dlang/DIPs/pull/123

And one more reminder that Walter's DIP, "Add Bottom Type", will be leaving Draft Review soon:

https://github.com/dlang/DIPs/pull/117

On 04/06/2018 5:01 PM, Mike Parker wrote:
> Named arguments lite

I'm concerned about this DIP (keep in mind I wrote a referenced WIP DIP).

1. Reordering of parameters that match (with overloads)

```D
int add(int a, int b);
int add(int b, int a) { ... }
```

This part of the DIP needs quite a bit of filling out and I expect to have a lot of corner cases.

Are you saying that you have an add that is extern'd or do you mean a named argument function overload? By conventional wisdom it definitely should error out.

I'm sure somebody else can think of more problems with this with regards to types.

2. All or nothing.

```D
int add(int x, int y);
@named:
int add(int b, int a) { ... }
```

This is one of the reasons some people /don't/ want named arguments and have said that they out right would not use a language with it.

3. Admittedly this is meant to be a cut down version, so I'll leave this use case here which named arguments should fix (I think).

```D
void main() {
	log("hi!");
	log(moduleName: "woot", lineNumber: 7, "bye");
}

void log(T...)(T args, <string moduleName = __MODULE__, uint lineNumber = __LINE__>) {
    writeln(moduleName, "[", lineNumber, "] ", args);
}
```

On Monday, 4 June 2018 at 05:46:04 UTC, rikki cattermole wrote:
> On 04/06/2018 5:01 PM, Mike Parker wrote:
>> Named arguments lite
>
> I'm concerned about this DIP (keep in mind I wrote a referenced WIP DIP).
>

The place for this sort of feedback is in the PR comments, not here :-)

On Monday, 4 June 2018 at 05:46:04 UTC, rikki cattermole wrote:
> On 04/06/2018 5:01 PM, Mike Parker wrote:
>> Named arguments lite
>
> I'm concerned about this DIP (keep in mind I wrote a referenced WIP DIP).
>
> 1. Reordering of parameters that match (with overloads)
>
> ```D
> int add(int a, int b);
> int add(int b, int a) { ... }
> ```
>
> This part of the DIP needs quite a bit of filling out and I expect to have a lot of corner cases.
>
> Are you saying that you have an add that is extern'd or do you mean a named argument function overload? By conventional wisdom it definitely should error out.

Not sure what you meant? This definitely does not error out: https://godbolt.org/g/PAiFPw

>
> 2. All or nothing.
>
> ```D
> int add(int x, int y);
> @named:
> int add(int b, int a) { ... }
> ```
>
> This is one of the reasons some people /don't/ want named arguments and have said that they out right would not use a language with it.
>

Care to elaborate why? In this DIP, name prefix on caller side is optional, caller is allowed to leave out any number of argument names if they want.

On 04/06/2018 10:05 PM, Yuxuan Shui wrote:
> On Monday, 4 June 2018 at 05:46:04 UTC, rikki cattermole wrote:
>> On 04/06/2018 5:01 PM, Mike Parker wrote:
>>> Named arguments lite
>>
>> I'm concerned about this DIP (keep in mind I wrote a referenced WIP DIP).
>>
>> 1. Reordering of parameters that match (with overloads)
>>
>> ```D
>> int add(int a, int b);
>> int add(int b, int a) { ... }
>> ```
>>
>> This part of the DIP needs quite a bit of filling out and I expect to have a lot of corner cases.
>>
>> Are you saying that you have an add that is extern'd or do you mean a named argument function overload? By conventional wisdom it definitely should error out.
> 
> Not sure what you meant? This definitely does not error out: https://godbolt.org/g/PAiFPw

```D
@named:
int add(int a, int b);
int add(int b, int a) {
	assert(a > 0);
	return a + b;
}

void main() {
	add(2, 0);
}
```

>>
>> 2. All or nothing.
>>
>> ```D
>> int add(int x, int y);
>> @named:
>> int add(int b, int a) { ... }
>> ```
>>
>> This is one of the reasons some people /don't/ want named arguments and have said that they out right would not use a language with it.
>>
> 
> Care to elaborate why? In this DIP, name prefix on caller side is optional, caller is allowed to leave out any number of argument names if they want.

Not all parameters should be used as named arguments. Two syntax's one purpose isn't desired, which the DIP currently encourages.

Personally I want to keep named and unnamed completely separate and focus more upon public API.



While I'm not keen on 2 and definitely would love for 3, my first point is what will determine if I vote yes or not (assuming it gets there). My instincts are saying that it simply hasn't been thought through enough just yet and that there will be some real trouble with it.

Ambiguity is nobody's friend when it comes to programming language proposals. You have time to think it over, and I could be very wrong (of course); but other wise as a lite version of named arguments its not a bad DIP, just maybe we can do better for D ;)

On Monday, 4 June 2018 at 10:30:18 UTC, rikki cattermole wrote:
> On 04/06/2018 10:05 PM, Yuxuan Shui wrote:
>> On Monday, 4 June 2018 at 05:46:04 UTC, rikki cattermole wrote:
>>> [...]
>> 
>> Not sure what you meant? This definitely does not error out: https://godbolt.org/g/PAiFPw
>
> ```D
> @named:
> int add(int a, int b);
> int add(int b, int a) {
> 	assert(a > 0);
> 	return a + b;
> }
>
> void main() {
> 	add(2, 0);
> }
> ```
>

This shouldn't fail to compile. I think it's made clear in the DIP, parameter names play no role in overload resolution.

>>>[...]
>> 
>> Care to elaborate why? In this DIP, name prefix on caller side is optional, caller is allowed to leave out any number of argument names if they want.
>
> Not all parameters should be used as named arguments. Two syntax's one purpose isn't desired, which the DIP currently encourages.

Why is this two syntaxes one purpose?

>
> Personally I want to keep named and unnamed completely separate and focus more upon public API.
>
>
>
> While I'm not keen on 2 and definitely would love for 3, my first point is what will determine if I vote yes or not (assuming it gets there). My instincts are saying that it simply hasn't been thought through enough just yet and that there will be some real trouble with it.

I've dwelt on this for a couple of months now, and keeping thinking on it myself is not going to help. That's why I'm asking for feedback.

>
> Ambiguity is nobody's friend when it comes to programming language proposals. You have time to think it over, and I could be very wrong (of course); but other wise as a lite version of named arguments its not a bad DIP, just maybe we can do better for D ;)

On 04/06/2018 10:39 PM, Yuxuan Shui wrote:
> I've dwelt on this for a couple of months now, and keeping thinking on it myself is not going to help. That's why I'm asking for feedback.

Hum

Changes possible usage syntax, given that the only attribute that does this currently is @property which people want to remove (as it mostly does nothing), a pragma might be a better option.

```D
pragma(namedParameters, true):
```

By making it a pragma, it also makes it an override for a future possible extension (e.g. my DIP with better syntax). So that it becomes a compiler extension not a language feature.

If no future DIP to extend it happens, a dedicated attribute can be added instead (like you have).



Changes summarized:

1. Overload resolution does not change
2. Arguments (named names gets erased as far as overload resolution is concerned)
3. When multiple definitions of a function prototype are found with types of parameters matching and is not templated then the names will go into a single definition in the AST for a given scope. These alternative names can be used for verification with named arguments, but all arguments names must match a single set of parameter names and cannot be mixed.
	Thought: Couldn't we have alternative names in the parameter instead? E.g.
```D
void foo(int x/x0/width, int y/y0/height){}
```
	This simplifies having to keep whole prototypes around (which can be a real pain especially with templates that it would otherwise not work for).
4. New calling syntax ``Identifier : ConditionalExpression``
	FIXME: fix your DIP to that FYI, ``foo(width:x=7)`` probably isn't what you want to have supported.

I'll copy this into the PR comments if I haven't misunderstood something big.

On Monday, 4 June 2018 at 11:28:26 UTC, rikki cattermole wrote:

> 	Thought: Couldn't we have alternative names in the parameter instead? E.g.
> ```D
> void foo(int x/x0/width, int y/y0/height){}
> ```

This intuitively means that any combination of the parameter names would work (e.g. (x, y0), (width, y)), which is not what we want.

On 05/06/2018 3:45 AM, Yuxuan Shui wrote:
> On Monday, 4 June 2018 at 11:28:26 UTC, rikki cattermole wrote:
> 
>>     Thought: Couldn't we have alternative names in the parameter instead? E.g.
>> ```D
>> void foo(int x/x0/width, int y/y0/height){}
>> ```
> 
> This intuitively means that any combination of the parameter names would work (e.g. (x, y0), (width, y)), which is not what we want.

You will need to amend the DIP to confirm that a primary use case (alternative names) is not usable with templated functions if you do not want to do an alternative method.