4 ms·

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes need

Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :) I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...

orlp 2mo ago
This is the opposite, it is further opting out of flexibility.
- eqvinox 2mo ago
  I guess the point is that the concepts are needed, which is true. But the Rust way (more explicit and targeted) of dealing with these concepts seems better than how either C++ or D handle it.
  - germandiago 2mo ago
    Yes, I meant the concepts needed for low level language and tweaking when high performance is of concern.
- deleted 2mo ago
  [deleted]
giancarlostoro 2mo ago
D is my favorite language that I wish I could use more, but the chances of me being paid to use it are too low, I wish that job market would expand, I feel like D needs a really good alternative to Vibe.d a web framework with a well designed ORM, or a rich GUI stack out of the box. Go became massive because a production ready but simple HTTP server came out of the box, and other nice to haves that made being productive in Go a breeze from day 1.
- germandiago 2mo ago
  I also like d a lot even if I did not use it that much (toolchain and getting things done problems mostly, besides not great platform support). The metaprogramming of D is really impressive. In fact I considered using Vibe.d for some backend: it has fibers. I love stackful coros in general (virtual threads in Java, for example). Way more than stackless for most uses. But I am afraid that Vibe.d could not be flexible enough. With Java, Python, etc. I have more than enough for my needs right now.
kibwen 2mo ago
To be clear, this is absolutely not adding any sort of C++-style overrideable implicit move or copy constructor to Rust. There's not really any relationship to C++ in this proposal, it's just a step towards opt-in linear types.
- panstromek 2mo ago
  It's relevant for C++ interop at least, but that's about it.
MaxBarraclough 2mo ago
For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler. https://github.com/AdaCore/ada-spark-rfcs/blob/master/features/rfc-oop-constructors.rst https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur... https://github.com/AdaCore/ada-spark-rfcs/blob/master/features/rfc-oop-destructors.rst https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur... https://gcc.gnu.org/gcc-16/changes.html#ada https://gcc.gnu.org/gcc-16/changes.html#ada

orlp 2mo ago

This is the opposite, it is further opting out of flexibility.

eqvinox 2mo ago
I guess the point is that the concepts are needed, which is true. But the Rust way (more explicit and targeted) of dealing with these concepts seems better than how either C++ or D handle it.
- germandiago 2mo ago
  Yes, I meant the concepts needed for low level language and tweaking when high performance is of concern.
deleted 2mo ago
[deleted]

giancarlostoro 2mo ago

D is my favorite language that I wish I could use more, but the chances of me being paid to use it are too low, I wish that job market would expand, I feel like D needs a really good alternative to Vibe.d a web framework with a well designed ORM, or a rich GUI stack out of the box. Go became massive because a production ready but simple HTTP server came out of the box, and other nice to haves that made being productive in Go a breeze from day 1.

germandiago 2mo ago
I also like d a lot even if I did not use it that much (toolchain and getting things done problems mostly, besides not great platform support). The metaprogramming of D is really impressive. In fact I considered using Vibe.d for some backend: it has fibers. I love stackful coros in general (virtual threads in Java, for example). Way more than stackless for most uses. But I am afraid that Vibe.d could not be flexible enough. With Java, Python, etc. I have more than enough for my needs right now.

kibwen 2mo ago

To be clear, this is absolutely not adding any sort of C++-style overrideable implicit move or copy constructor to Rust. There's not really any relationship to C++ in this proposal, it's just a step towards opt-in linear types.

panstromek 2mo ago
It's relevant for C++ interop at least, but that's about it.

MaxBarraclough 2mo ago

For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler. https://github.com/AdaCore/ada-spark-rfcs/blob/master/features/rfc-oop-constructors.rst https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur... https://github.com/AdaCore/ada-spark-rfcs/blob/master/features/rfc-oop-destructors.rst https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur... https://gcc.gnu.org/gcc-16/changes.html#ada https://gcc.gnu.org/gcc-16/changes.html#ada