Thank you! (page 4)

Settings

Help

Index » General » Thank you! (page 4)

September 08, 2021

Re: Thank you!

Posted by Mike Parker
in reply to Tejas

Permalink

Mike Parker

Posted in reply to Tejas

Permalink

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.

September 08, 2021

Re: Thank you!

Posted by Tejas
in reply to Ali Çehreli

Permalink

Tejas

Posted in reply to Ali Çehreli

Permalink

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

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

<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

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

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?

September 08, 2021

Re: Thank you!

Posted by Mike Parker
in reply to Tejas

Permalink

Mike Parker

Posted in reply to Tejas

Permalink

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

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:

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.

September 08, 2021

Re: Thank you!

Posted by Tejas
in reply to Tejas

Permalink

Tejas

Posted in reply to Tejas

Permalink

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

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.

September 08, 2021

Re: Thank you!

Posted by drug
in reply to Guillaume Piolat

Permalink

drug

Posted in reply to Guillaume Piolat

Permalink

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.

September 08, 2021

Re: Thank you!

Posted by Tejas
in reply to Mike Parker

Permalink

Tejas

Posted in reply to Mike Parker

Permalink

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:

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:

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

September 08, 2021

Re: Thank you!

Posted by bauss
in reply to drug

Permalink

bauss

Posted in reply to drug

Permalink

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.

September 08, 2021

Re: Thank you!

Posted by Mike Parker
in reply to drug

Permalink

Mike Parker

Posted in reply to drug

Permalink

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.

September 08, 2021

Re: Thank you!

Posted by Steven Schveighoffer
in reply to Mike Parker

Permalink

Steven Schveighoffer

Posted in reply to Mike Parker

Permalink

On 9/8/21 3:25 AM, Mike Parker wrote:

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

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:

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

September 08, 2021

Re: Thank you!

Posted by Mike Parker
in reply to Tejas

Permalink

Mike Parker

Posted in reply to Tejas

Permalink

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

Top | Forum index | About this forum

Forums