Order of evaluation for named arguments (page 3)

Settings

Help

Index » General » Order of evaluation for named arguments (page 3)

2 days ago

Re: Order of evaluation for named arguments

Posted by monkyyy
in reply to claptrap

Permalink

monkyyy

Posted in reply to claptrap

Permalink

On Monday, 31 March 2025 at 23:16:57 UTC, claptrap wrote:

On Monday, 31 March 2025 at 21:43:07 UTC, Salih Dincer wrote:

On Monday, 31 March 2025 at 19:47:01 UTC, Richard (Rikki) Andrew Cattermole wrote:

[...]

If the probability is low, as Jonathan emphasizes, then please change the behavior of the D compiler. Or if not, in this case, here is the intermediate solution:

Add a warning or error message

"Named arguments are evaluated in parameter order, so be mindful of side effects!"

Or just require that parameters are always passed in the same order as the declaration. Makes this bug impossible, and no silent breakage.

Doesnt that make the whole thing meaningless

2 days ago

Re: Order of evaluation for named arguments

Posted by Salih Dincer
in reply to claptrap

Permalink

Salih Dincer

Posted in reply to claptrap

Permalink

In this case, the named arguments will have no meaning. It's such a thing that it sets you free; when you assign arguments default values. In the past, this facility did not exist and I used to feel very stuck.

SDB@79

1 day ago

Re: Order of evaluation for named arguments

Posted by Ogion
in reply to Daniel N

Permalink

Ogion

Posted in reply to Daniel N

Permalink

On Sunday, 30 March 2025 at 09:14:49 UTC, Daniel N wrote:

I think you are overlooking one important detail, StructInitializer, it must match named arguments and fortunately it does.

import std.stdio;
struct S { int a, b; }

int fun(int v)
{
    v.writeln;
    return v;
}

void main()
{
	S r;
	S s = { b:fun(1), a:fun(2) };
}

2
1

Same with ArrayInitializer:

import std.stdio;

int fun(int v)
{
   v.writeln;
   return v;
}

void main() {
   int[2] a = [ 1:fun(1), 0:fun(2) ];
}

1
2

1 day ago

Re: Order of evaluation for named arguments

Posted by Ogion
in reply to Ogion

Permalink

Ogion

Posted in reply to Ogion

Permalink

On Tuesday, 1 April 2025 at 09:05:59 UTC, Ogion wrote:

Same with ArrayInitializer:

import std.stdio;

int fun(int v)
{
   v.writeln;
   return v;
}

void main() {
 int[2] a = [ 1:fun(1), 0:fun(2) ];
}

1
2

Correction:
2
1

1 day ago

Re: Order of evaluation for named arguments

Posted by claptrap
in reply to monkyyy

Permalink

claptrap

Posted in reply to monkyyy

Permalink

On Tuesday, 1 April 2025 at 02:04:44 UTC, monkyyy wrote:

On Monday, 31 March 2025 at 23:16:57 UTC, claptrap wrote:

On Monday, 31 March 2025 at 21:43:07 UTC, Salih Dincer wrote:

On Monday, 31 March 2025 at 19:47:01 UTC, Richard (Rikki) Andrew Cattermole wrote:

[...]

If the probability is low, as Jonathan emphasizes, then please change the behavior of the D compiler. Or if not, in this case, here is the intermediate solution:

Add a warning or error message

"Named arguments are evaluated in parameter order, so be mindful of side effects!"

Or just require that parameters are always passed in the same order as the declaration. Makes this bug impossible, and no silent breakage.

Doesnt that make the whole thing meaningless

I thought the point was to document at call site, ie clarify long parameter lists, and enable skipping defaults?

I mean I don't see the point of just being able to change the order the parameters are passed in?

1 day ago

Re: Order of evaluation for named arguments

Posted by monkyyy
in reply to claptrap

Permalink

monkyyy

Posted in reply to claptrap

Permalink

On Tuesday, 1 April 2025 at 11:26:34 UTC, claptrap wrote:

On Tuesday, 1 April 2025 at 02:04:44 UTC, monkyyy wrote:

On Monday, 31 March 2025 at 23:16:57 UTC, claptrap wrote:

On Monday, 31 March 2025 at 21:43:07 UTC, Salih Dincer wrote:

On Monday, 31 March 2025 at 19:47:01 UTC, Richard (Rikki) Andrew Cattermole wrote:

[...]

If the probability is low, as Jonathan emphasizes, then please change the behavior of the D compiler. Or if not, in this case, here is the intermediate solution:

Add a warning or error message

"Named arguments are evaluated in parameter order, so be mindful of side effects!"

Or just require that parameters are always passed in the same order as the declaration. Makes this bug impossible, and no silent breakage.

Doesnt that make the whole thing meaningless

I thought the point was to document at call site, ie clarify long parameter lists, and enable skipping defaults?

I mean I don't see the point of just being able to change the order the parameters are passed in?

Im still waiting on named argument templates disambiguation but im worried about expressiveness

For example raylib has like 20 draw functions in a c verbose style; it be nice to overload them all; but oh no draw line and draw rectangle overlap (4 arguments, two x's and y's)

in thoery after named argument works with templates you can redirect via parsing the .h defination easily

1 day ago

Re: Order of evaluation for named arguments

Posted by Patrick Schluter
in reply to claptrap

Permalink

Patrick Schluter

Posted in reply to claptrap

Permalink

On Tuesday, 1 April 2025 at 11:26:34 UTC, claptrap wrote:

On Tuesday, 1 April 2025 at 02:04:44 UTC, monkyyy wrote:

On Monday, 31 March 2025 at 23:16:57 UTC, claptrap wrote:

On Monday, 31 March 2025 at 21:43:07 UTC, Salih Dincer wrote:

[...]

Or just require that parameters are always passed in the same order as the declaration. Makes this bug impossible, and no silent breakage.

Doesnt that make the whole thing meaningless

I thought the point was to document at call site, ie clarify long parameter lists, and enable skipping defaults?

I mean I don't see the point of just being able to change the order the parameters are passed in?

It can happen that you change the order of parameter at the definition site. This should not require modiying all call sites with named arguments.

1 day ago

Re: Order of evaluation for named arguments

Posted by Walter Bright
in reply to Timon Gehr

Permalink

Walter Bright

Posted in reply to Timon Gehr

Permalink

On 3/31/2025 7:46 AM, Timon Gehr wrote:
> On 3/30/25 23:04, Paul Backus wrote:
>> It will also silently *fix* existing code that was written under the assumption that the spec was correct.

If they didn't realize their code was producing the wrong results before, I don't see how they'd realize it was producing correct results later.

> I am also just not a big fan of accident-driven language design where compiler bugs are codified into the spec.

Breaking existing code has repeatedly driven people away from D.

The difficulty with making this change is there's no way to detect if there is a conflict, unless there's an additional requirement that the arguments be pure.

1 day ago

Re: Order of evaluation for named arguments

Posted by Walter Bright
in reply to Jonathan M Davis

Permalink

Walter Bright

Posted in reply to Jonathan M Davis

Permalink

On 3/30/2025 6:21 PM, Jonathan M Davis wrote:
> It might, but most folks don't even realize that named arguments are a thing
> in D, and most code doesn't rely on the order of evaluation of the arguments
> to a function. As such, I would expect that the amount of code that would
> actually break would be extremely small (and possibly zero).
> 
> Most bug fixes risk silently breaking some piece of code that accidentally
> relied on the broken behavior, and I think this is a case where the odds of
> it actually causing problems are sufficiently low that it's worth just
> making it all consistent - and the sooner we do it, the less likely it is to
> break any code.

It's a good argument, but we really have no idea how much code depends on named arguments. I'm also really tired of the vitriol we get when breaking existing code.

1 day ago

Re: Order of evaluation for named arguments

Posted by claptrap
in reply to Patrick Schluter

Permalink

claptrap

Posted in reply to Patrick Schluter

Permalink

On Tuesday, 1 April 2025 at 17:13:45 UTC, Patrick Schluter wrote:

On Tuesday, 1 April 2025 at 11:26:34 UTC, claptrap wrote:

On Tuesday, 1 April 2025 at 02:04:44 UTC, monkyyy wrote:

On Monday, 31 March 2025 at 23:16:57 UTC, claptrap wrote:

On Monday, 31 March 2025 at 21:43:07 UTC, Salih Dincer wrote:

[...]

Or just require that parameters are always passed in the same order as the declaration. Makes this bug impossible, and no silent breakage.

Doesnt that make the whole thing meaningless

I thought the point was to document at call site, ie clarify long parameter lists, and enable skipping defaults?

I mean I don't see the point of just being able to change the order the parameters are passed in?

It can happen that you change the order of parameter at the definition site. This should not require modiying all call sites with named arguments.

It'd still break all call sites that don't use named parameters, maybe even silently if you're not careful. So its a thin argument IMO, changing the order of the parameters just seems like a bad idea, its just breakage, for nothing.

Top | Forum index | About this forum

Forums