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.
replyhttps://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
This is the opposite, it is further opting out of flexibility.
replyI 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.
replydeleted
replyD 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.
replyI 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).
replyThe 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.
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.
replyIt's relevant for C++ interop at least, but that's about it.
reply