Thank you!
Tejas
notrealemail at gmail.com
Tue Sep 7 05:01:30 UTC 2021
On Tuesday, 7 September 2021 at 01:34:01 UTC, Basile B. wrote:
> On Wednesday, 1 September 2021 at 04:40:37 UTC, Виталий Фадеев
> wrote:
>> I want say "Thank you!" to all who works under D.
>>
>> I see the result of your work, even if it is small, even the
>> size of a byte.
>> I use D and see your gift.
>> I like. :)
>
> while this code looks natural and obvious, although pointless
>
> ```d
> module m;
>
> struct S { int i; }
>
> S _s;
>
> S s (){return _s;}
>
> void main()
> {
> s().i = 42;
> }
> ```
>
> the reality is that `i` can only be accessed through a pointer
> to a `S` (you want a deref of the address plus a offset).but
> `s` returns a `S` by value... so a temporary is created.
>
> All the time we write code that compiles but this code just
> compiles because the front end will help us, in this case, by
> turning `s()` into a lvalue.
>
> so we can indeed say thanks. what you think just works actually
> requires some unexpected rewrites, like **all the time**.
Don't you think it would be better to raise a warning though
instead of silently fixing it?
It would help people understand the differences between `structs`
and `classes` better, and when they will be using them in a much
more complex set of circumstances where the compiler won't be
able to detect what they're doing, they'll use them the right way.
This seems like setting them up for frustration in the future,
since one can definitely run into a case where `struct` will
purely be treated as a value type and then the user will feel
that the behaviour is inconsistent with what they've experienced.
This reminds me of single length string literals being treated as
a character.
```d
void main(){
char[5] a = "y";//shouldn't compile, but it does
char[5] b = 'y';
writeln(a);
writeln(b);
}
Output:
y
yyyyy
```
Was it a good thing that the compiler rewrote the string into a
char in this case? Wouldn't it be better if an error/warning was
provided instead?
More information about the Digitalmars-d
mailing list