www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP Draft Review News

reply Mike Parker <aldacron gmail.com> writes:
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
Jun 03 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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);
}
```
Jun 03 2018
next sibling parent Mike Parker <aldacron gmail.com> writes:
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 :-)
Jun 04 2018
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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.
Jun 04 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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 ;)
Jun 04 2018
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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 ;)
Jun 04 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jun 04 2018
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
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.
Jun 04 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jun 04 2018