Re: DIP Draft Review News
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.
Re: DIP Draft Review News
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.
Re: DIP Draft Review News
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.
Re: DIP Draft Review News
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 ;)
Re: DIP Draft Review News
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 ;)
Re: DIP Draft Review News
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.
Re: DIP Draft Review News
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 :-)
Re: DIP Draft Review News
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, = __LINE__>) {
writeln(moduleName, "[", lineNumber, "] ", args);
}
```
DIP Draft Review News
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
