Menu
Search

Forums

Forum Index

3 days ago
Gravatar of Daniel NPosted by Daniel N
in reply to Steven Schveighoffer		Reply
Daniel N
Gravatar of Daniel N
Posted in reply to Steven Schveighoffer


Reply

On Saturday, 29 March 2025 at 18:38:31 UTC, Steven Schveighoffer wrote:

>

In the D spec, the function parameter section on order of evaluation says:

>

Arguments are evaluated left to right.

So a question was raised, what about named arguments, since those might not match the order of parameters?

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

3 days ago
Gravatar of Salih DincerPosted by Salih Dincer
in reply to Daniel N		Reply
Salih Dincer
Gravatar of Salih Dincer
Posted in reply to Daniel N


Reply

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.

It's a great perspective, but I don't think it's directly related to our topic. I've tried to increase the value below, but I haven't been successful in establishing relevance. 😇

auto inc(T)(ref T value)
{
    scope(exit)
        value.writeln;
    return ++value;
}

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

void main()
{
    auto x = 41;
    x.writeln;

    S s = {
      b : inc(x),
      a : inc(x)
    };

    s.writeln;
}

SDB@79

3 days ago
Gravatar of Salih DincerPosted by Salih Dincer
in reply to Salih Dincer		Reply
Salih Dincer
Gravatar of Salih Dincer
Posted in reply to Salih Dincer


Reply

On Sunday, 30 March 2025 at 09:40:10 UTC, Salih Dincer wrote:

>

...I don't think it's directly related to our topic...

Like I said, there's no relevance/problem here. Because there is no ordering from the right or the left. The compiler selects and initials it according to the order in the struct.

    enum fun = (int v) => v;

    S r = { b:fun(1), a:fun(2) };
    r.writeln; // S(2, 1)

SDB@79

3 days ago
Gravatar of Walter BrightPosted by Walter Bright
in reply to Salih Dincer		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Salih Dincer


Reply
In principle I agree with you, but on a pragmatic note this will silently break existing code.
3 days ago
Gravatar of Paul BackusPosted by Paul Backus
in reply to Walter Bright		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Walter Bright


Reply
On Sunday, 30 March 2025 at 17:45:07 UTC, Walter Bright wrote:
> In principle I agree with you, but on a pragmatic note this will silently break existing code.

It will also silently *fix* existing code that was written under the assumption that the spec was correct.
3 days ago
Gravatar of Jonathan M DavisPosted by Jonathan M Davis
in reply to Walter Bright		Reply
Jonathan M Davis
Gravatar of Jonathan M Davis
Posted in reply to Walter Bright


Reply
On Sunday, March 30, 2025 11:45:07 AM MDT Walter Bright via Digitalmars-d wrote:
> In principle I agree with you, but on a pragmatic note this will silently break existing code.

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.

- Jonathan M Davis
2 days ago
Gravatar of Timon GehrPosted by Timon Gehr
in reply to Paul Backus		Reply
Timon Gehr
Gravatar of Timon Gehr
Posted in reply to Paul Backus


Reply
On 3/30/25 23:04, Paul Backus wrote:
> On Sunday, 30 March 2025 at 17:45:07 UTC, Walter Bright wrote:
>> In principle I agree with you, but on a pragmatic note this will silently break existing code.
> 
> It will also silently *fix* existing code that was written under the assumption that the spec was correct.

I am also just not a big fan of accident-driven language design where compiler bugs are codified into the spec.
2 days ago
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Steven Schveighoffer		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Steven Schveighoffer


Reply
I've been thinking about this situation for a few days.

I recognize that changing the compiler may not be a simple task.

My conclusion about the specification is that an attempt was made to define D so that the order of evaluation is always as written left to right. See comma expression for a near identical evaluation definition.

Before named arguments were added, the arguments list and parameter list orders matched, so a poorly written description was accurate.

However with named arguments the distinction between a called function parameter list dictating the matched argument list order, and the order as written by the user argument list, became meaningful.

It is my view that the order of evaluation should mirror that of the programmer, or at least be predictable. Named arguments entirely eliminate this predictability as a possibility as the order of evaluation could change over time or be in any position "unknown" to the user.

Right now the order in which arguments are written do not contribute to evaluation ordering. Although I suspect that this is more of an oversight then what is intended.

Regardless the spec here needs some work done to make this clearer, because it is confusing the called functions definition against the arguments list.
2 days ago
Gravatar of Salih DincerPosted by Salih Dincer
in reply to Richard (Rikki) Andrew Cattermole		Reply
Salih Dincer
Gravatar of Salih Dincer
Posted in reply to Richard (Rikki) Andrew Cattermole


Reply

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

>

It is my view that the order of evaluation should mirror that of the programmer, or at least be predictable. Named arguments entirely eliminate this predictability as a possibility as the order of evaluation could change over time or be in any position "unknown" to the user.

+1

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!"

If this behavior is intentional, it at least needs to be clearly communicated. In summary, we cannot get away with changing the specification. Because this is an unintuitive situation.

SDB@79

2 days ago
Gravatar of claptrapPosted by claptrap
in reply to Salih Dincer		Reply
claptrap
Gravatar of claptrap
Posted in reply to Salih Dincer


Reply

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:

>

It is my view that the order of evaluation should mirror that of the programmer, or at least be predictable. Named arguments entirely eliminate this predictability as a possibility as the order of evaluation could change over time or be in any position "unknown" to the user.

+1

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.

« First   ‹ Prev
1 2 3 4
Next ›   Last »