Menu
Search

Forums

Forum Index

Thread overview
Named Arguments Status Update - Overloading by name
Apr 09
Uranuz
Apr 09
Uranuz
Apr 10
jmh530
Apr 10
jmh530
Apr 10
bachmeier
Apr 10
jmh530
April 09
Gravatar of UranuzPosted by UranuzReply
Uranuz
Gravatar of Uranuz


Reply
https://forum.dlang.org/post/uo1jj3$151c$1@digitalmars.com

On Sunday, 14 January 2024 at 21:27:00 UTC, Walter Bright wrote:
> On 1/11/2024 12:33 PM, Dennis wrote:
>> On Thursday, 11 January 2024 at 19:21:46 UTC, Walter Bright wrote:
>>> It's ok if the error is detected after instantiation. It can be detected by testing to see if the mangled signature (which is generated for the type of the function) already exists.
>> 
>> That is the second option I listed in my opening post, which can be implemented easily.
>> However, it would create a compile time 'race condition': the `f!short` instantiation which dmd sees first may succeed, but any subsequent attempts will fail.
>> 
>> I don't know if this will result in inscrutable errors in practice, but it very well may.
>
>
> string f(T)(T x) if (T.sizeof <= 2) { return "x"; }
> string f(T)(T y) if (T.sizeof >= 2) { return "y"; }
>
> Then the only thing to do is disallow an overload that differs only in the parameter names.

Hello! I have a question. Why you decided to use ":" symbol as separator of name and value of parameter in function call syntax? For aestetical reason "=" looks better (at my opinion).
f(x=2, y=10)
Maybe this is because I have Python background where "=" is used for this? ;-)

But in static initializer syntax ":" symbol looks better for me:
struct A {
  int a;
  int b;
};
{ a: 1, b: 2 }

Maybe it is because I also have Python and JavaScript background? So it looks like JSON format.

Also one thing in D that I still cannot accomodate to is associative array literals with [square brackets]. I'am used to that JSON, JavaScript objects use curly {curly braces} for object literal. And also this is the same for Python.
{ "a": 3, "b": 4 }
But in dlang I should use:
[ "a": 3, "b": 4 ]
This is a little confusing, because I develop web application in D and JavaScript. So I need to rememeber this difference in basic syntax every time.

I understand that this is kind of *holly war* theme. But it's still interesting
April 10
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Uranuz		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Uranuz


Reply
On 10/04/2024 8:49 AM, Uranuz wrote:
> Hello! I have a question. Why you decided to use ":" symbol as separator of name and value of parameter in function call syntax? For aestetical reason "=" looks better (at my opinion). f(x=2, y=10) Maybe this is because I have Python background where "=" is used for this? ;-)

It is already used for AssignExp which is also a valid argument.

Whereas : is used with struct initializer syntax so has a comparable use case in both D and the C family.
April 09
Gravatar of UranuzPosted by Uranuz
in reply to Richard (Rikki) Andrew Cattermole		Reply
Uranuz
Gravatar of Uranuz
Posted in reply to Richard (Rikki) Andrew Cattermole


Reply
On Tuesday, 9 April 2024 at 20:52:48 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 10/04/2024 8:49 AM, Uranuz wrote:
>> Hello! I have a question. Why you decided to use ":" symbol as separator of name and value of parameter in function call syntax? For aestetical reason "=" looks better (at my opinion). f(x=2, y=10) Maybe this is because I have Python background where "=" is used for this? ;-)
>
> It is already used for AssignExp which is also a valid argument.
>
> Whereas : is used with struct initializer syntax so has a comparable use case in both D and the C family.

I was thinking that assignment could be the reason, because assigment could have some return value.
April 09
Gravatar of Lance BachmeierPosted by Lance Bachmeier
in reply to Uranuz		Reply
Lance Bachmeier
Gravatar of Lance Bachmeier
Posted in reply to Uranuz


Reply

On Tuesday, 9 April 2024 at 21:15:59 UTC, Uranuz wrote:

>

I was thinking that assignment could be the reason, because assigment could have some return value.

Not just that, but also the way you can write function calls as assignments, even when you wouldn't expect it. A very nice feature when you have a use for it, but it also lets rebels write stuff like this:

import std;

void main() {
    writeln(f=4.7);
    auto h=g(f=4.7);
    writeln(h);
}

double f(double x) {
    return 2.5*x;
}

double g(double x) {
    return 2.5*x;
}
April 10
Gravatar of Alexandru ErmicioiPosted by Alexandru Ermicioi
in reply to Richard (Rikki) Andrew Cattermole		Reply
Alexandru Ermicioi
Gravatar of Alexandru Ermicioi
Posted in reply to Richard (Rikki) Andrew Cattermole


Reply

On Tuesday, 9 April 2024 at 20:52:48 UTC, Richard (Rikki) Andrew Cattermole wrote:

>

Whereas : is used with struct initializer syntax so has a comparable use case in both D and the C family.

Groovy also uses : for named arguments.

April 10
Gravatar of jmh530Posted by jmh530
in reply to Lance Bachmeier		Reply
jmh530
Gravatar of jmh530
Posted in reply to Lance Bachmeier


Reply

On Tuesday, 9 April 2024 at 21:33:21 UTC, Lance Bachmeier wrote:

>

On Tuesday, 9 April 2024 at 21:15:59 UTC, Uranuz wrote:

>

I was thinking that assignment could be the reason, because assigment could have some return value.

Not just that, but also the way you can write function calls as assignments, even when you wouldn't expect it. A very nice feature when you have a use for it, but it also lets rebels write stuff like this:

import std;

void main() {
    writeln(f=4.7);
    auto h=g(f=4.7);
    writeln(h);
}

double f(double x) {
    return 2.5*x;
}

double g(double x) {
    return 2.5*x;
}

That's a new one for me! Not sure I would want to make a habit of that though!

April 10
Gravatar of jmh530Posted by jmh530
in reply to jmh530		Reply
jmh530
Gravatar of jmh530
Posted in reply to jmh530


Reply

On Wednesday, 10 April 2024 at 12:00:42 UTC, jmh530 wrote:

>

On Tuesday, 9 April 2024 at 21:33:21 UTC, Lance Bachmeier wrote:

>

On Tuesday, 9 April 2024 at 21:15:59 UTC, Uranuz wrote:

>

I was thinking that assignment could be the reason, because assigment could have some return value.

Not just that, but also the way you can write function calls as assignments, even when you wouldn't expect it. A very nice feature when you have a use for it, but it also lets rebels write stuff like this:

import std;

void main() {
    writeln(f=4.7);
    auto h=g(f=4.7);
    writeln(h);
}

double f(double x) {
    return 2.5*x;
}

double g(double x) {
    return 2.5*x;
}

That's a new one for me! Not sure I would want to make a habit of that though!

That line with auto h can also be written auto h = g = f = 4.7; and you get the same result.

Learn something new every day, I guess. The function spec [1] doesn't talk about this, but it must be something with an assign expression [2] of f = a getting re-written to f(a) for functions.

[1] https://dlang.org/spec/function.html
[2] https://dlang.org/spec/expression.html#assign_expressions

April 10
Gravatar of bachmeierPosted by bachmeier
in reply to jmh530		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to jmh530


Reply

On Wednesday, 10 April 2024 at 12:18:06 UTC, jmh530 wrote:

>

That line with auto h can also be written auto h = g = f = 4.7; and you get the same result.

Learn something new every day, I guess. The function spec [1] doesn't talk about this, but it must be something with an assign expression [2] of f = a getting re-written to f(a) for functions.

[1] https://dlang.org/spec/function.html
[2] https://dlang.org/spec/expression.html#assign_expressions

I learned about it from the properties chapter in Ali's book: http://ddili.org/ders/d.en/property.html

It's particularly useful for clean interfaces when you're wrapping structs allocated by a C library. You may have to do various operations behind the scenes, like converting D strings to their C counterparts so the data can be used internally, but you still want to be able to work with it in the natural way x.names = ["blue", "green", "red"].

April 10
Gravatar of jmh530Posted by jmh530
in reply to bachmeier		Reply
jmh530
Gravatar of jmh530
Posted in reply to bachmeier


Reply

On Wednesday, 10 April 2024 at 13:47:19 UTC, bachmeier wrote:

>

[snip]

I learned about it from the properties chapter in Ali's book: http://ddili.org/ders/d.en/property.html

It's particularly useful for clean interfaces when you're wrapping structs allocated by a C library. You may have to do various operations behind the scenes, like converting D strings to their C counterparts so the data can be used internally, but you still want to be able to work with it in the natural way x.names = ["blue", "green", "red"].

I knew you could do that with member functions, just never thought to do it with normal functions. Thanks!

April 19
Gravatar of Markelov69Posted by Markelov69
in reply to bachmeier		Reply
Markelov69
Gravatar of Markelov69
Posted in reply to bachmeier


Reply

On Wednesday, 10 April 2024 at 13:47:19 UTC, bachmeier wrote:

>

On Wednesday, 10 April 2024 at 12:18:06 UTC, jmh530 wrote:

>

That line with auto h can also be written auto h = g = f = 4.7; and you get the same result.

Learn something new every day, I guess. The function spec [1] doesn't talk about this, but it must be something with an assign expression [2] of f = a getting re-written to f(a) for functions.

[1] https://dlang.org/spec/function.html
[2] https://plnkgame.com
[3] https://dlang.org/spec/expression.html#assign_expressions

I learned about it from the properties chapter in Ali's book: http://ddili.org/ders/d.en/property.html

It's particularly useful for clean interfaces when you're wrapping structs allocated by a C library. You may have to do various operations behind the scenes, like converting D strings to their C counterparts so the data can be used internally, but you still want to be able to work with it in the natural way x.names = ["blue", "green", "red"].

Thank you!