Re: Safety is not what you think
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?
[1]: https://dlang.org/spec/expression.html
An hypothesis is that this makes codegening the pre and the
post variants almost identical. The only difference is what is
yield.
[Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383).
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
```d
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:
```d
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:
```d
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.
Re: Safety is not what you think
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? [1]: https://dlang.org/spec/expression.html An hypothesis is that this makes codegening the pre and the post variants almost identical. The only difference is what is yield. [Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383). 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 ```d int a,b; int c = rand(); ((c & 3) ? a : b) = 42; ```
Re: Safety is not what you think
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
Re: Safety is not what you think
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:
```d
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][1], 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 ``.
This definitely isn't allowed in C or C++. I wonder what the
rationale is for having this behavior in D?
[1]: https://dlang.org/spec/expression.html
Safety is not what you think
I want to share a stupid program to show you that D safety is
more complex than you might think:
```d
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 ;)
