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