Comment by germandiago

10 hours ago

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/DIP1...

8 comments

germandiago

Reply
orlp  10 hours ago

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

  • eqvinox  9 hours 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.

giancarlostoro  9 hours 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  9 hours 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  9 hours 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.