In the spirit of the old genera "PHP people solving problems that they only have because they're using PHP" (and similar for C, regexs, rails, etc.) we're starting to see a whole new ecosystem developing around rust.
sestep•6mo ago
More specifically, it seems like this is a problem for people using async Rust.
ericyd•6mo ago
I don't really understand your comment - people addressing issues specific to their language is unnatural or bad?
MarkusQ•6mo ago
Not at all! It's great when a language (or anything) gets an active community that's working to identify and ameliorate its pain points.
My point is that these occasionally break out of their bubbles and become more "mainstream" than you might expect from the raw population-of-interest numbers. It's not all that uncommon (e.g. for a while there were more "how I cope with the difficulties that come from living off grid" stories out there than "how to live off grid" or even "why live off grid?") but I still find it noteworthy.
kibwen•6mo ago
No, in-place construction is something that all systems-level languages need to deal with due to the fact that the fundamental abstraction of "a function" inherently gives you limited control over how any arbitrary function returns its return value to its caller, which sometimes is highly relevant for maximum performance.
C deals with it via passing outparams, C++ deals with it via a bunch of machinery that literally has multiple entire Wikipedia articles dedicated to it ( https://en.wikipedia.org/wiki/Placement_syntax and https://en.wikipedia.org/wiki/Copy_elision ), and Rust has historically sought for a solution that's less explicit than C's and less fraught than C++'s, so far to little success, because (to reiterate) functions don't particularly want to work that way.
munificent•6mo ago
C# has out parameters that sort of cover this use case.
gpderetta•6mo ago
Interestingly copy elision in C++ originally exists as a language feature because copy and move constructors are user-overridable and thus observable, so an explicit elision rule was required to allow the compiler to call the copy constructor fewer times than expected.
Rust doesn't have overridable copy/move, so elision could be treated as QoI issue.
More interestingly, now that C++ has guaranteed copy elision in some cases, in addition to allow returning non copyable objects, code that doesn't override constructors can rely on the address of an returned object not changing that open up some possibilities. I assume rust wants this.
MarkusQ•6mo ago
sestep•6mo ago
ericyd•6mo ago
MarkusQ•6mo ago
My point is that these occasionally break out of their bubbles and become more "mainstream" than you might expect from the raw population-of-interest numbers. It's not all that uncommon (e.g. for a while there were more "how I cope with the difficulties that come from living off grid" stories out there than "how to live off grid" or even "why live off grid?") but I still find it noteworthy.
kibwen•6mo ago
C deals with it via passing outparams, C++ deals with it via a bunch of machinery that literally has multiple entire Wikipedia articles dedicated to it ( https://en.wikipedia.org/wiki/Placement_syntax and https://en.wikipedia.org/wiki/Copy_elision ), and Rust has historically sought for a solution that's less explicit than C's and less fraught than C++'s, so far to little success, because (to reiterate) functions don't particularly want to work that way.
munificent•6mo ago
gpderetta•6mo ago
Rust doesn't have overridable copy/move, so elision could be treated as QoI issue.
More interestingly, now that C++ has guaranteed copy elision in some cases, in addition to allow returning non copyable objects, code that doesn't override constructors can rely on the address of an returned object not changing that open up some possibilities. I assume rust wants this.