www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thank you!

reply =?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KTQsNC0?= =?UTF-8?B?0LXQtdCy?= writes:
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. :)
Aug 31 2021
next sibling parent reply russhy <russhy gmail.com> writes:
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. :)


I also would like to take a moment to thank everyone who is 
working on D, it is the best language we have out there, i wish i 
discovered it earlier, i had to suffer with C++ for a very long 
time... but i'm happy to say that i am now C++ free :)

Thanks everybody
Sep 01 2021
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 01, 2021 at 10:55:39PM +0000, russhy via Digitalmars-d 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. :)


 
 I also would like to take a moment to thank everyone who is working on
 D, it is the best language we have out there, i wish i discovered it
 earlier, i had to suffer with C++ for a very long time... but i'm
 happy to say that i am now C++ free :)


[...]

I also came from a C/C++ background.  I used to have a pretty complex
personal project written in C++, and as time went on it became more and
more unwieldy and unmaintainable, and adding new features became harder
and harder.  After I found D, I rewrote the whole thing from scratch in
less than a quarter of the time, and ended up with something much less
buggy and significantly easier to maintain.  Now I would never choose
C++ again for any project.


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond
Sep 01 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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. :)


Happy that you like it. Soon D will take off 😁
Sep 02 2021
parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 2 September 2021 at 17:43:32 UTC, Imperatorn 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. :)


 Happy that you like it. Soon D will take off 😁


Not to throw shade at D or anything, since it by far is my 
favorite language.

However, D will never take off because D has an identity crisis 
that it'll never fix, on-top of its constant political issues 
that pushes some core contributors away.

I wish it would take off, but it hasn't taken off in the past 2 
decades, so it probably won't in the next 2 either.
Sep 05 2021
next sibling parent reply drug <drug2004 bk.ru> writes:
06.09.2021 09:51, bauss ΠΏΠΈΡˆΠ΅Ρ‚:

 On Thursday, 2 September 2021 at 17:43:32 UTC, Imperatorn 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. :)


 Happy that you like it. Soon D will take off 😁


 
 Not to throw shade at D or anything, since it by far is my favorite 
 language.
 


it's my favorite too, but


 However, D will never take off because D has an identity crisis that 
 it'll never fix, on-top of its constant political issues that pushes 
 some core contributors away.
 


Unfortunately I agree to you. When I started using D this forum was the 
brilliant place where many smart guys shared different information and I 
learnt many useful things here. But currently it is quiet and boring 
place because (I guess) the community lost many its core contributors 
and continue to do it. No offense intended.


 I wish it would take off, but it hasn't taken off in the past 2 decades, 
 so it probably won't in the next 2 either.
Sep 06 2021
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Monday, 6 September 2021 at 08:15:02 UTC, drug wrote:

 Unfortunately I agree to you. When I started using D this forum 
 was the brilliant place where many smart guys shared different 
 information and I learnt many useful things here. But currently 
 it is quiet and boring place because (I guess) the community 
 lost many its core contributors and continue to do it. No 
 offense intended.


Or it could be the case that you already know most of discussed 
stuff, and it is not as brilliant as it was when discovered for 
first time :).
Sep 06 2021
parent reply drug <drug2004 bk.ru> writes:
06.09.2021 16:11, Alexandru Ermicioi ΠΏΠΈΡˆΠ΅Ρ‚:

 On Monday, 6 September 2021 at 08:15:02 UTC, drug wrote:

 Unfortunately I agree to you. When I started using D this forum was 
 the brilliant place where many smart guys shared different information 
 and I learnt many useful things here. But currently it is quiet and 
 boring place because (I guess) the community lost many its core 
 contributors and continue to do it. No offense intended.


 
 Or it could be the case that you already know most of discussed stuff, 
 and it is not as brilliant as it was when discovered for first time :).
 


I hope so :)
Sep 07 2021
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 7 September 2021 at 07:34:40 UTC, drug wrote:

 Or it could be the case that you already know most of 
 discussed stuff, and it is not as brilliant as it was when 
 discovered for first time :).
 


 I hope so :)


Perhaps read some of the old rants then: 
https://dlang-group.iteye.com/group/topic/20404
A lot of theses issues were solved, and not thanks to the rant.

The old forums were good but also a festering ground for all 
kinds of flamewars.
Sep 07 2021
parent reply drug <drug2004 bk.ru> writes:
07.09.2021 15:37, Guillaume Piolat ΠΏΠΈΡˆΠ΅Ρ‚:

 On Tuesday, 7 September 2021 at 07:34:40 UTC, drug wrote:

 Or it could be the case that you already know most of discussed 
 stuff, and it is not as brilliant as it was when discovered for first 
 time :).


 I hope so :)


 
 Perhaps read some of the old rants then: 
 https://dlang-group.iteye.com/group/topic/20404
 A lot of theses issues were solved, and not thanks to the rant.
 
 The old forums were good but also a festering ground for all kinds of 
 flamewars.


My concern wans't about D itself, it was about the community. More 
accurately I wouldn't state that D won't take off at all, but I would 
state that without the community the language will die. Of course I 
can't see the situation as a whole but I got the impression that too 
many D developers have left due to political issues. Bearophile, Hara 
Kenji (9rnsr), joakim-noah for example. I don't know the truth, it's 
just my impression.
Sep 08 2021
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 8 September 2021 at 07:51:29 UTC, drug wrote:

 07.09.2021 15:37, Guillaume Piolat ΠΏΠΈΡˆΠ΅Ρ‚:

 On Tuesday, 7 September 2021 at 07:34:40 UTC, drug wrote:

 Or it could be the case that you already know most of 
 discussed stuff, and it is not as brilliant as it was when 
 discovered for first time :).


 I hope so :)


 
 Perhaps read some of the old rants then: 
 https://dlang-group.iteye.com/group/topic/20404
 A lot of theses issues were solved, and not thanks to the rant.
 
 The old forums were good but also a festering ground for all 
 kinds of flamewars.


 My concern wans't about D itself, it was about the community. 
 More accurately I wouldn't state that D won't take off at all, 
 but I would state that without the community the language will 
 die. Of course I can't see the situation as a whole but I got 
 the impression that too many D developers have left due to 
 political issues. Bearophile, Hara Kenji (9rnsr), joakim-noah 
 for example. I don't know the truth, it's just my impression.


You're entirely right. The problem isn't the language at all. The 
problems are all the politic issues that exist. It has existed 
for D since early days, like how the community was split up with 
tango.

The language is fairly stable and can be used for almost 
anything, while library support isn't the greatest then it's not 
bad either.

However the politic issues are so terrible and while it has been 
worse then there's still so many improvements to be made.

However even with the improvements then it won't fix the past 
issues.

Some resolved political issues still remain outside of the 
community, because others still think they're relevant like 
people still thinking there are two standard libraries etc.
Sep 08 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 08:32:01 UTC, bauss wrote:

 On Wednesday, 8 September 2021 at 07:51:29 UTC, drug wrote:

 [...]


 You're entirely right. The problem isn't the language at all. 
 The problems are all the politic issues that exist. It has 
 existed for D since early days, like how the community was 
 split up with tango.

 The language is fairly stable and can be used for almost 
 anything, while library support isn't the greatest then it's 
 not bad either.

 However the politic issues are so terrible and while it has 
 been worse then there's still so many improvements to be made.

 However even with the improvements then it won't fix the past 
 issues.

 Some resolved political issues still remain outside of the 
 community, because others still think they're relevant like 
 people still thinking there are two standard libraries etc.


Although I have known about D since ~2018, I only started 
actively visiting the forums and actually using it a little since 
June this year.

What political issues are you talking about?
Sep 08 2021
parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 8 September 2021 at 12:12:57 UTC, Tejas wrote:

 On Wednesday, 8 September 2021 at 08:32:01 UTC, bauss wrote:

 On Wednesday, 8 September 2021 at 07:51:29 UTC, drug wrote:

 [...]


 You're entirely right. The problem isn't the language at all. 
 The problems are all the politic issues that exist. It has 
 existed for D since early days, like how the community was 
 split up with tango.

 The language is fairly stable and can be used for almost 
 anything, while library support isn't the greatest then it's 
 not bad either.

 However the politic issues are so terrible and while it has 
 been worse then there's still so many improvements to be made.

 However even with the improvements then it won't fix the past 
 issues.

 Some resolved political issues still remain outside of the 
 community, because others still think they're relevant like 
 people still thinking there are two standard libraries etc.


 Although I have known about D since ~2018, I only started 
 actively visiting the forums and actually using it a little 
 since June this year.

 What political issues are you talking about?


People disagreeing with the future of the language, its design, 
standard library and management in general.

There was a huge discussion recently due to some PR or something 
being reverted and people took sides on whether they 
agreed/disagreed with that.

Some contributors even left because of it.

And it's not something new, as it has happened many times before.

There were used to be a split about the standard library too, 
where there existed 2 "standard" libraries.

One official and then tango (which of course is somewhat 
discontinued and has been for years) - which separated the whole 
community into two groups, those who used tango and those who 
didn't and often code using phobos couldn't be used with code 
that used tango.

That's no longer an issue but you'll still once in a while hear 
people bring it up as if it's a current issue.

There are many more.

Personally I don't care much about all these issues but I've seen 
them hurt the community over all so many times.
Sep 08 2021
parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 13:25:44 UTC, bauss wrote:

 On Wednesday, 8 September 2021 at 12:12:57 UTC, Tejas wrote:

 [...]


 People disagreeing with the future of the language, its design, 
 standard library and management in general.

 There was a huge discussion recently due to some PR or 
 something being reverted and people took sides on whether they 
 agreed/disagreed with that.

 Some contributors even left because of it.

 And it's not something new, as it has happened many times 
 before.

 There were used to be a split about the standard library too, 
 where there existed 2 "standard" libraries.

 One official and then tango (which of course is somewhat 
 discontinued and has been for years) - which separated the 
 whole community into two groups, those who used tango and those 
 who didn't and often code using phobos couldn't be used with 
 code that used tango.

 That's no longer an issue but you'll still once in a while hear 
 people bring it up as if it's a current issue.

 There are many more.

 Personally I don't care much about all these issues but I've 
 seen them hurt the community over all so many times.


That's the problem of being pure open source and community 
driven, I guess...

It sucks, but I agree with Mike when he says that the fact we 
have gotten this far is a marvel.

Here's to hoping a future D3 will get rid of these problems 
forever!!
Sep 08 2021
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 September 2021 at 07:51:29 UTC, drug wrote:


 My concern wans't about D itself, it was about the community. 
 More accurately I wouldn't state that D won't take off at all, 
 but I would state that without the community the language will 
 die. Of course I can't see the situation as a whole but I got 
 the impression that too many D developers have left due to 
 political issues. Bearophile, Hara Kenji (9rnsr), joakim-noah 
 for example. I don't know the truth, it's just my impression.


Churn is natural. We've lost people over disagreements about 
management and process, personal issues, and other reasons. None 
of the names I used to see here every day when I first joined the 
community in 2003 are around anymore other than Walter, and many 
of them haven't been for ages. I wish we could keep the top 
contributors around forever, but people volunteering their time 
will always allocate it in the way that best fits their interests.

My impression is that we have more active contributors now than 
we have ever had. Razvan mentioned something to me recently about 
putting out some pull request stats to show the progression over 
time. I don't know if that will validate my impression or not, 
but it will be interesting to see.

I don't think we can read too much into the level of forum 
activity these days. Many new people who come into the community 
go straight to Discord and don't touch the forums. The channels 
there are fairly active. That's definitely a generational thing, 
I think. I also notice that many of them do not have the sort of 
C background we used to be able to reasonably expect new users 
would have.

Plenty of people are still hanging out on IRC, and when regular 
contributors have specific questions about development and 
maintenance, they usually go to Slack for that where once they 
might have come to the forums instead. I see people in those 
Slack threads who don't show up in the forums anymore.

 From my perspective, the D community is more vibrant than ever. 
It's got a different vibe now than before, definitely, but I 
don't see that as a bad thing.
Sep 08 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 6 September 2021 at 06:51:20 UTC, bauss wrote:

 Not to throw shade at D or anything, since it by far is my 
 favorite language.

 However, D will never take off because D has an identity crisis 
 that it'll never fix, on-top of its constant political issues 
 that pushes some core contributors away.

 I wish it would take off, but it hasn't taken off in the past 2 
 decades, so it probably won't in the next 2 either.


We need developers, developers, developers, developers, 
developers. Like that cringe Steve Ballmer moment. I don't know 
what Steve Ballmer is doing today but he is not at Microsoft 
anymore. Maybe we should hire him.
Sep 06 2021
next sibling parent surlymoor <surlymoor cock.li> writes:
On Monday, 6 September 2021 at 19:35:19 UTC, IGotD- wrote:

 We need developers, developers, developers, developers, 
 developers. Like that cringe Steve Ballmer moment. I don't know 
 what Steve Ballmer is doing today but he is not at Microsoft 
 anymore. Maybe we should hire him.


Iff his contract states that every in-person dconf will begin 
with his running onto stage, sweaty and shirtless, repeating that 
(in)famous line.
Sep 06 2021
prev sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Monday, 6 September 2021 at 19:35:19 UTC, IGotD- wrote:

 We need developers, developers, developers, developers, 
 developers. Like that cringe Steve Ballmer moment. I don't know 
 what Steve Ballmer is doing today but he is not at Microsoft 
 anymore. Maybe we should hire him.


D has/had numerous developers very few of us could rival. I 
definitely notice a lot less of the "elite" here than I used to 
in the 2014-2016ish period. I've also noticed a decline in talk 
about the language's future direction on this forum, as I assume 
the Slack and Discord is where most of that is happening now.

I wonder where all the action is now. I've said before that these 
forums used to have something exciting posted about the 
language's direction pretty at a relatively often pace, but now 
it seems to be a special occasion when something noteworthy is 
announced.

Hopefully it's all being saved for DConf >:3

/incoherent_unstructured_nonsense
Sep 07 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 7 September 2021 at 22:48:23 UTC, SealabJaster wrote:

 On Monday, 6 September 2021 at 19:35:19 UTC, IGotD- wrote:

 [...]


 D has/had numerous developers very few of us could rival. I 
 definitely notice a lot less of the "elite" here than I used to 
 in the 2014-2016ish period. I've also noticed a decline in talk 
 about the language's future direction on this forum, as I 
 assume the Slack and Discord is where most of that is happening 
 now.

 I wonder where all the action is now. I've said before that 
 these forums used to have something exciting posted about the 
 language's direction pretty at a relatively often pace, but now 
 it seems to be a special occasion when something noteworthy is 
 announced.

 Hopefully it's all being saved for DConf >:3

 /incoherent_unstructured_nonsense


That could also be because the language is getting small 
improvements all the time and focus is on stability and 
consistency rather than new things.
Sep 07 2021
parent SealabJaster <sealabjaster gmail.com> writes:
On Tuesday, 7 September 2021 at 23:26:08 UTC, Imperatorn wrote:

 That could also be because the language is getting small 
 improvements all the time and focus is on stability and 
 consistency rather than new things.


That is very much true.
Sep 07 2021
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
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**.
Sep 06 2021
parent reply Tejas <notrealemail gmail.com> writes:
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?
Sep 06 2021
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


This example works with a initialized to "yy" as well, or "yyxx". 
The chars not provided are initialized to 0 (rather than 255 if 
the variable weren't initialized at all). This seems like a nice 
way to reuse a large fixed buffer that initially has small 
relevant content, like `char[255] line = "hello";`

It doesn't initialize the entire array to 'y', so it's not 
treating "y" as the same as 'y'.
Sep 06 2021
next sibling parent Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 05:09:39 UTC, jfondren wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


 This example works with a initialized to "yy" as well, or 
 "yyxx". The chars not provided are initialized to 0 (rather 
 than 255 if the variable weren't initialized at all). This 
 seems like a nice way to reuse a large fixed buffer that 
 initially has small relevant content, like `char[255] line = 
 "hello";`

 It doesn't initialize the entire array to 'y', so it's not 
 treating "y" as the same as 'y'.


Oh... that looks more convenient than
```d
char[10] a;
a[0..5] = 'y';
```

Can't even initialize `a` with index `0` at point of declaration 
unless size of definition is same as size of array, basically 
making
```d
char[10] a = [0:'y',1:'y',2:'y',3:'y',4:'y'];
```
impossible.

Agh, maybe that thing needs to exist after all
Sep 06 2021
prev sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Tuesday, 7 September 2021 at 05:09:39 UTC, jfondren wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


 This example works with a initialized to "yy" as well, or 
 "yyxx". The chars not provided are initialized to 0 (rather 
 than 255 if the variable weren't initialized at all). This 
 seems like a nice way to reuse a large fixed buffer that 
 initially has small relevant content, like `char[255] line = 
 "hello";`

 It doesn't initialize the entire array to 'y', so it's not 
 treating "y" as the same as 'y'.


Seems strange to only permit this with a string literal though.

```d
unittest {
     char[3] a;
     char[2] b = '!';

     // this is OK
     a = "!!";
     assert(a == [33, 33, 0]);

     // Error: mismatched array lengths, 3 and 2
     assert(!__traits(compiles, a = ['!', '!']));
     assert(!__traits(compiles, { a[] = b[]; }));
}
```
Sep 06 2021
parent Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 05:36:17 UTC, jfondren wrote:

 On Tuesday, 7 September 2021 at 05:09:39 UTC, jfondren wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


 This example works with a initialized to "yy" as well, or 
 "yyxx". The chars not provided are initialized to 0 (rather 
 than 255 if the variable weren't initialized at all). This 
 seems like a nice way to reuse a large fixed buffer that 
 initially has small relevant content, like `char[255] line = 
 "hello";`

 It doesn't initialize the entire array to 'y', so it's not 
 treating "y" as the same as 'y'.


 Seems strange to only permit this with a string literal though.

 ```d
 unittest {
     char[3] a;
     char[2] b = '!';

     // this is OK
     a = "!!";
     assert(a == [33, 33, 0]);

     // Error: mismatched array lengths, 3 and 2
     assert(!__traits(compiles, a = ['!', '!']));
     assert(!__traits(compiles, { a[] = b[]; }));
 }
 ```



You can work around this problem with designated initializers

```d
void main(){
     char[3] a = [0:'!', /*no need for "1:"*/'!', 2:char.init/*you 
  MUST assign explicitly to the last member of the array otherwise 
you get mismatched length error for some reason. Also note that 
this is only necessary when you use "0:" */];
     a[0 .. b.length] = b[];//this is the only way since a and b 
are of different types
}
```
Sep 07 2021
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


What you think is happening is not actually what's happening.

It's not turning the string into a char. It's actually copying 
the contents of the string (char array) into the char array.

It's evident by:

```d
char[5] c = "hello";
```

c will be "hello"

And in the case of ex.

```d
char[5] c = "hello world!";
```

You actually get a runtime error but arguably it should be a 
compile-time error since the size of c and the size of the string 
is available at compile-time.

I would agree with that it shouldn't be allowed at all however, 
but unfortunately this is allowed because string is really an 
alias for an array and not a type in itself.
Sep 06 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 06:12:38 UTC, bauss wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


 What you think is happening is not actually what's happening.

 It's not turning the string into a char. It's actually copying 
 the contents of the string (char array) into the char array.

 It's evident by:

 ```d
 char[5] c = "hello";
 ```

 c will be "hello"

 And in the case of ex.

 ```d
 char[5] c = "hello world!";
 ```

 You actually get a runtime error but arguably it should be a 
 compile-time error since the size of c and the size of the 
 string is available at compile-time.

 I would agree with that it shouldn't be allowed at all however, 
 but unfortunately this is allowed because string is really an 
 alias for an array and not a type in itself.


Nope, there is definitely some special-casing going on here.

The following doesn't work:
```d
import std.stdio;

void main(){
     immutable (char)[] s = "hello";
     char[5] a = s;
     writeln(a);
     immutable (int)[] i = [10];
     writeln(i);
     int[] I = i;
}
```
Turn `I` into a static array, and you get runtime error for some 
strange reason.

This is an inconsistency.

But considering the use case presented by  jfondren, I'm not sure 
whether we should remove it for consistency's sake
Sep 06 2021
parent bauss <jj_1337 live.dk> writes:
On Tuesday, 7 September 2021 at 06:45:02 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 06:12:38 UTC, bauss wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


 What you think is happening is not actually what's happening.

 It's not turning the string into a char. It's actually copying 
 the contents of the string (char array) into the char array.

 It's evident by:

 ```d
 char[5] c = "hello";
 ```

 c will be "hello"

 And in the case of ex.

 ```d
 char[5] c = "hello world!";
 ```

 You actually get a runtime error but arguably it should be a 
 compile-time error since the size of c and the size of the 
 string is available at compile-time.

 I would agree with that it shouldn't be allowed at all 
 however, but unfortunately this is allowed because string is 
 really an alias for an array and not a type in itself.


 Nope, there is definitely some special-casing going on here.

 The following doesn't work:
 ```d
 import std.stdio;

 void main(){
     immutable (char)[] s = "hello";
     char[5] a = s;
     writeln(a);
     immutable (int)[] i = [10];
     writeln(i);
     int[] I = i;
 }
 ```
 Turn `I` into a static array, and you get runtime error for 
 some strange reason.

 This is an inconsistency.

 But considering the use case presented by  jfondren, I'm not 
 sure whether we should remove it for consistency's sake


Yeah, what I was saying is that there's some funky thing going on 
but that it wasn't turning the string into a char but rather 
somehow attempting to copy the string into the char array.
Sep 07 2021
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 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?


no. as compiler experiment people can add a flag to generated 
temproaries and then printf on a visitor for VarExp and then will 
probabably be surprised by the amount of message printf'd like 
2567 times

"look boy am saving expressivity for ya here"


 It would help people understand the differences between [...]
Sep 07 2021
next sibling parent Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 08:46:48 UTC, Basile B. wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 01:34:01 UTC, Basile B. wrote:

 [...]


 Don't you think it would be better to raise a warning though 
 instead of silently fixing it?


 no. as compiler experiment people can add a flag to generated 
 temproaries and then printf on a visitor for VarExp and then 
 will probabably be surprised by the amount of message printf'd 
 like 2567 times

 "look boy am saving expressivity for ya here"


 It would help people understand the differences between [...]




Can you please show me how to do it? I don't know of the cmd line 
arg that does this (`vgc-ast`? But then how do you make it print 
certain nodes?)
Sep 07 2021
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 08:46:48 UTC, Basile B. wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 01:34:01 UTC, Basile B. wrote:

 [...]


 Don't you think it would be better to raise a warning though 
 instead of silently fixing it?


 no. as compiler experiment people can add a flag to generated 
 temproaries and then printf on a visitor for VarExp and then 
 will probabably be surprised by the amount of message printf'd 
 like 2567 times

 "look boy am saving expressivity for ya here"


 It would help people understand the differences between [...]






```d
import std.stdio;

struct S { int i; }

S _s;

S s (){return _s;}

void main()
{
     s().i = 42;
     writeln(_s.i == 42);
}

Output:
false
```

Wow, compiler help much appreciated
Sep 07 2021
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 7 September 2021 at 13:36:39 UTC, Tejas wrote:

 ```d
 import std.stdio;

 struct S { int i; }

 S _s;

 S s() {return _s;}

 void main()
 {
     s().i = 42;
     writeln(_s.i == 42);
 }

 Output:
 false
 ```

 Wow, compiler help much appreciated


Is this confusing to you? I might be missing your point. It isn’t 
confusing to me, `struct`s are value types. If you want `s()` to 
return a reference to `_s` it should be declared as returning a 
reference:

```d
import std.stdio;

struct S { int i; }

S _s;

ref S s() {return _s;}

void main()
{
     s().i = 42;
     writeln(_s.i == 42);
}

Output:
true
```

β€”Bastiaan.
Sep 07 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Tuesday, 7 September 2021 at 21:43:02 UTC, Bastiaan Veelo 
wrote:

 On Tuesday, 7 September 2021 at 13:36:39 UTC, Tejas wrote:

 ```d
 import std.stdio;

 struct S { int i; }

 S _s;

 S s() {return _s;}

 void main()
 {
     s().i = 42;
     writeln(_s.i == 42);
 }

 Output:
 false
 ```

 Wow, compiler help much appreciated


 Is this confusing to you? I might be missing your point. It 
 isn’t confusing to me, `struct`s are value types. If you want 
 `s()` to return a reference to `_s` it should be declared as 
 returning a reference:

 ```d
 import std.stdio;

 struct S { int i; }

 S _s;

 ref S s() {return _s;}

 void main()
 {
     s().i = 42;
     writeln(_s.i == 42);
 }

 Output:
 true
 ```

 β€”Bastiaan.


The people that don't find this confusing will never even write 
`S` alone as a return type in the first place.

Again, I said that this is setting people up for frustration in 
the future, and I stick to it.

Do you really think people who are writing code like that expect 
a temporary to be generated? What else could be the purpose of 
returning an existing struct and using it as an `lvalue` if not 
to modify it?

I feel we would be better off if the same
```d
<your_var_name> is not an lvalue and cannot be modified
```

error that is raised for other similar cases came up in the 
original version of this code. It will catch a (almost 100% 
guranteed) runtime error during compile time _and_ be consistent 
with the rest of the language.
Sep 07 2021
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/7/21 9:36 PM, Tejas wrote:


 S _s;

 S s() {return _s;}






[...]


 Do you really think people who are writing code like that expect a
 temporary to be generated?


I think so. Even if they don't, I can't imagine this being a big 
surprise in the future; a little test would reveal that _s was not changing.


 What else could be the purpose of returning
 an existing struct and using it as an `lvalue` if not to modify it?


The returned copy is not an lvalue; it is an rvalue.


 I feel we would be better off if the same
 ```d
 <your_var_name> is not an lvalue and cannot be modified
 ```


rvalues cannot be assigned to but they can be modified. The reason I 
don't find this surprising must be my past experience with C++, where it 
is exactly the same.


 error that is raised for other similar cases came up in the original
 version of this code. It will catch a (almost 100% guranteed) runtime
 error during compile time _and_ be consistent with the rest of the
 language.


How? Being value types, structs are consistently passed and returned by 
value. Otherwise, we wouldn't be able to write a factory function:

S makeS() {
   return S();  // Should this be returning a reference to a temporary?
}

Ali
Sep 07 2021
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 05:07:03 UTC, Ali Γ‡ehreli wrote:

 On 9/7/21 9:36 PM, Tejas wrote:


 S _s;

 S s() {return _s;}






 [...]


 Do you really think people who are writing code like that


 expect a

 temporary to be generated?


 I think so. Even if they don't, I can't imagine this being a 
 big surprise in the future; a little test would reveal that _s 
 was not changing.


It's not a big surprise, I agree; but it _is_ a gotcha.


 What else could be the purpose of returning
 an existing struct and using it as an `lvalue` if not to


 modify it?

 The returned copy is not an lvalue; it is an rvalue.


Yes, it is an rvalue, which is then assigned to a temporary and 
then that temporary is used as an `lvalue`
```d
auto __temp = s();
__temp.i = 42; //this is what is happening behind the scenes, 
according to my knowledge
```
But the user might be thinking that they're modifying `_s`, not 
some intermediate temporary.
Again, it can easily be figured out via a small test, so not a 
very big deal, but could be a little annoying to discover at 
runtime.


 I feel we would be better off if the same
 ```d
 <your_var_name> is not an lvalue and cannot be modified
 ```


 rvalues cannot be assigned to


Which is exactly what the original code is doing.


  but they can be modified.


I agree; you taught me that previously in an operator overloading 
thread :)



 How? Being value types, structs are consistently passed and 
 returned by value. Otherwise, we wouldn't be able to write a 
 factory function:

 S makeS() {
   return S();  // Should this be returning a reference to a 
 temporary?
 }


No, it should return by value, but you  wouldn't use it as
```d
makeS().i = 100;
```

And then expect `makeS().i == 100` to be true, would you?

My problem is that the original code returned an _existing_ 
`struct`, which implies that the struct itself is being returned, 
not a duplicate of it(even though after one understands that 
`structs` are value types they'll start using `ref S` instead of 
`S`).

I'm not saying a function that returns a `struct` should return 
the struct by reference; but if that function is being used in 
the left hand side of an assignment statement _and_ it is 
returning a **named** value(`_s` here), I think its reasonable 
for the compiler to at least emit a warning that the value 
returned by the function is not usable beyond the scope of that 
statement.


And if none of the above convinces anyone

```d
int integer;
int func(){
     return integer;
}
void main(){
     func() = 30;
}
Output:
onlineapp.d(29): Error: `func()` is not an lvalue and cannot be 
modified
```

Please allow this to compile.
`int` is value type, so it is fine to generate a temporary and 
allow the code to compile, right? A small test will reveal that 
`integer` is not being modified, so it's not **that** big of a 
deal, right?
Sep 07 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 September 2021 at 06:03:49 UTC, Tejas wrote:


 Please allow this to compile.
 `int` is value type, so it is fine to generate a temporary and 
 allow the code to compile, right? A small test will reveal that 
 `integer` is not being modified, so it's not **that** big of a 
 deal, right?


There's a big difference between int and struct: the latter is an 
aggregate that may have member functions that have side effects. 
For example:

```d
getTemporary().doSomethingWithSideEffects();
```

That's a valid pattern. You might then say that's a different 
case than the assignment in your example, but `opAssign` for a 
struct can be overridden.
Sep 08 2021
next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 07:25:52 UTC, Mike Parker wrote:

 On Wednesday, 8 September 2021 at 06:03:49 UTC, Tejas wrote:


 Please allow this to compile.
 `int` is value type, so it is fine to generate a temporary and 
 allow the code to compile, right? A small test will reveal 
 that `integer` is not being modified, so it's not **that** big 
 of a deal, right?


 There's a big difference between int and struct: the latter is 
 an aggregate that may have member functions that have side 
 effects. For example:

 ```d
 getTemporary().doSomethingWithSideEffects();
 ```

 That's a valid pattern. You might then say that's a different 
 case than the assignment in your example, but `opAssign` for a 
 struct can be overridden.


And what I'm saying is that the user _doesn't_ know that they're 
getting a temporary unless they're aware that `struct`s are value 
types. And in this particular case, `opAssign` isn't defined.

So I personally think this warrants a warning at the very least.

I would have 0 problems if the function returned `S(_s)` instead 
of `_s`.

But this has gone on long enough for me. Maybe I'm the only one 
who finds it unintuitive. Fair enough.
Sep 08 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 September 2021 at 08:27:13 UTC, Tejas wrote:


 And what I'm saying is that the user _doesn't_ know that 
 they're getting a temporary unless they're aware that `struct`s 
 are value types. And in this particular case, `opAssign` isn't 
 defined.

 So I personally think this warrants a warning at the very least.


Then the thing to do would be to open an issue in Bugzilla for an 
enhancement request and see what comes of it:

https://issues.dlang.org/
Sep 08 2021
parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 11:30:48 UTC, Mike Parker wrote:

 On Wednesday, 8 September 2021 at 08:27:13 UTC, Tejas wrote:


 And what I'm saying is that the user _doesn't_ know that 
 they're getting a temporary unless they're aware that 
 `struct`s are value types. And in this particular case, 
 `opAssign` isn't defined.

 So I personally think this warrants a warning at the very 
 least.


 Then the thing to do would be to open an issue in Bugzilla for 
 an enhancement request and see what comes of it:

 https://issues.dlang.org/


Done

https://issues.dlang.org/show_bug.cgi?id=22290
Sep 08 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/8/21 3:25 AM, Mike Parker wrote:

 On Wednesday, 8 September 2021 at 06:03:49 UTC, Tejas wrote:
 

 Please allow this to compile.
 `int` is value type, so it is fine to generate a temporary and allow 
 the code to compile, right? A small test will reveal that `integer` is 
 not being modified, so it's not **that** big of a deal, right?


 
 There's a big difference between int and struct: the latter is an 
 aggregate that may have member functions that have side effects. For 
 example:
 
 ```d
 getTemporary().doSomethingWithSideEffects();
 ```
 
 That's a valid pattern. You might then say that's a different case than 
 the assignment in your example, but `opAssign` for a struct can be 
 overridden.
 


But in this case, there is no side effect, and the compiler knows it.

TBH, I thought this was already disallowed, but run.dlang.io shows it as 
always succeeding.

One possible explanation is for generic code, but I don't buy that 
actually, because other rvalue/lvalue differences can cause generic code 
to not compile.

I would say disallowing assigning a non-elaborate field (one that is 
just a field, and does not call some arbitrary opAssign) would be a 
valid enhancement.

-Steve
Sep 08 2021
prev sibling parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 06:03:49 UTC, Tejas wrote:

 I'm not saying a function that returns a `struct` should return 
 the struct by reference; but if that function is being used in 
 the left hand side of an assignment statement _and_ it is 
 returning a **named** value(`_s` here), I think its reasonable 
 for the compiler to at least emit a warning that the value 
 returned by the function is not usable beyond the scope of that 
 statement.



Correction:
the compiler should emit a warning that the value being returned 
is a **duplicate** of the variable, and not a reference to the 
variable itself, and that the variable cannot be referred to 
after the statement ends.
Sep 08 2021
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 September 2021 at 04:36:44 UTC, Tejas wrote:

 Do you really think people who are writing code like that 
 expect a temporary to be generated?


Why wouldn't they? Structs are value types.
Sep 07 2021
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 7 September 2021 at 13:36:39 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 08:46:48 UTC, Basile B. wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 01:34:01 UTC, Basile B. wrote:

 [...]


 Don't you think it would be better to raise a warning though 
 instead of silently fixing it?


 no. as compiler experiment people can add a flag to generated 
 temproaries and then printf on a visitor for VarExp and then 
 will probabably be surprised by the amount of message printf'd 
 like 2567 times

 "look boy am saving expressivity for ya here"


 It would help people understand the differences between [...]






 ```d
 import std.stdio;

 struct S { int i; }

 S _s;

 S s (){return _s;}

 void main()
 {
     s().i = 42;
     writeln(_s.i == 42);
 }

 Output:
 false
 ```

 Wow, compiler help much appreciated


I see that the conversation has forked on the validity of this 
kind of code, so I've should have chosen a better example (set 
`i` storage to `__gshared`). The point was just to show that 
tempraries a created.
Sep 08 2021
parent Tejas <notrealemail gmail.com> writes:
On Wednesday, 8 September 2021 at 12:28:13 UTC, Basile B. wrote:

 On Tuesday, 7 September 2021 at 13:36:39 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 08:46:48 UTC, Basile B. wrote:

 On Tuesday, 7 September 2021 at 05:01:30 UTC, Tejas wrote:

 On Tuesday, 7 September 2021 at 01:34:01 UTC, Basile B. 
 wrote:

 [...]


 Don't you think it would be better to raise a warning though 
 instead of silently fixing it?


 no. as compiler experiment people can add a flag to generated 
 temproaries and then printf on a visitor for VarExp and then 
 will probabably be surprised by the amount of message 
 printf'd like 2567 times

 "look boy am saving expressivity for ya here"


 It would help people understand the differences between [...]






 ```d
 import std.stdio;

 struct S { int i; }

 S _s;

 S s (){return _s;}

 void main()
 {
     s().i = 42;
     writeln(_s.i == 42);
 }

 Output:
 false
 ```

 Wow, compiler help much appreciated


 I see that the conversation has forked on the validity of this 
 kind of code, so I've should have chosen a better example (set 
 `i` storage to `__gshared`). The point was just to show that 
 tempraries a created.


And I was arguing that that behavior should be either disabled(I 
don't feel this way anymore) or at least  emit a warning(still 
feel this way).

This isn't the first time, apparently:

https://issues.dlang.org/show_bug.cgi?id=3008

Even more troubling is this one, where `auto` decides to return 
`struct` by value rather than reference:
https://issues.dlang.org/show_bug.cgi?id=15231

The second one is more serious, I think.
No matter the default option picked by `auto`, it'll always be 
wrong in the other context.
Sep 08 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/7/21 1:01 AM, Tejas wrote:

 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


That is certainly an odd behavior. Looking at the resulting array, it's 
padded with 0s.


  Β Β Β Β  char[5] b = 'y';
  Β Β Β Β  writeln(a);
  Β Β Β Β  writeln(b);
 }
 
 
 Output:
 y
 yyyyy
 ```


This is not doing what you think it is doing. It's outputting 
essentially `"y\0\0\0\0"`, you just don't see the 0's on the console.


 
 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?


I think this "feature" should be removed, personally. Especially since 
it's not consistent with other array types.

-Steve
Sep 07 2021