Thread overview
Safety is not what you think
Jan 30
user1234
Feb 05
Basile B.
Feb 05
Basile B.
January 30

I want to share a stupid program to show you that D safety is more complex than you might think:

module test;

void test() @safe
{
    int i;
    int b = (*&(*&++i))++;
}

void main() @safe
{
    test();
}

I'm not showing a deficiency of D, that program is undeniably safe ;)

January 30

On Tuesday, 30 January 2024 at 02:05:23 UTC, user1234 wrote:

>

I want to share a stupid program to show you that D safety is more complex than you might think:

module test;

void test() @safe
{
    int i;
    int b = (*&(*&++i))++;
}

void main() @safe
{
    test();
}

I'm not showing a deficiency of D, that program is undeniably safe ;)

I'm surprised &++i even compiles in the first place, but looking at the spec, it seems to be intentional:

>

The following expressions, and no others, are called lvalue expressions or lvalues:

[...]
4. the result of the following expressions:

  • built-in unary operators + (when applied to an lvalue), *, ++ (prefix only), -- (prefix only);

Testing it out, the address you get is the same as &i.

This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D?

January 31

On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote:

>

This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D?

It isn't allowed in C, but allowed in C++

https://godbolt.org/z/9xTPhsb5G

As for rationale... I don't know why it wouldn't be allowed? You clearly need an lvalue to use prefix ++, and the result is the value after adding one, so why can't it be bound to a reference? I don't see where the problem would arise.

-Steve

February 05

On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote:

>

[...]
This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D?

An hypothesis is that this makes codegening the pre and the post variants almost identical. The only difference is what is yield. Proof.

Now there's not much to say about the topic, I just thought it was amusing to share that (user1234 is my noname nickname here) as people might not realize how much certain expressions allows.

In the same vein you have the possibility to select an lvalue with a conditional expression. Pretty sure nobody knows that the following is legal

int a,b;
int c = rand();
((c & 3) ? a : b) = 42;
February 05

On Monday, 5 February 2024 at 14:26:45 UTC, Basile B. wrote:

>

On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote:

>

[...]
This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D?

An hypothesis is that this makes codegening the pre and the post variants almost identical. The only difference is what is yield. Proof.

Now there's not much to say about the topic, I just thought it was amusing to share that (user1234 is my noname nickname here) as people might not realize how much certain expressions allows.

In the same vein you have the possibility to select an lvalue with a conditional expression. Pretty sure nobody knows that the following is legal

int a,b;
int c = rand();
((c & 3) ? a : b) = 42;

BTW, "achtung off topic", that's pretty much how the optional access can be an lvalue:

struct S {int a};
S* s;     // null, by default init
s?.a = 0; // no access violation !! + valgrind is happy

You can lower that to a conditional expression:

struct S {int a};
S* s;
typeof(S.a) __fallback; // compiler-generated
(s ? s.a : __fallback) = 0;

I've played a lot with that kind of expressions during the two last years. They're funny but apparently not good enough for D ;)

To conclude.