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.
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.
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.
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.
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.
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.
C# has out parameters that sort of cover this use case.
I don't really understand your comment - people addressing issues specific to their language is unnatural or bad?
More specifically, it seems like this is a problem for people using async Rust.