3 ms·
I won’t deny that the newtype pattern leaves a lot to be desired, but I think I’m practice this isn’t nearly as big a deal as you make it out to be. All that a
by stouset 3y ago
I won’t deny that the newtype pattern leaves a lot to be desired, but I think I’m practice this isn’t nearly as big a deal as you make it out to be.
All that aside,
> Especially when the solution is so simple.
This is completely unwarranted and presupposes incompetency or apathy on the Rust dev team, either of which couldn’t be farther from the truth.
Designing programming languages is hard and full of tradeoffs. While we can of course disagree about those tradeoffs, “simple” changes like these are never actually simple in practice and involve complex sets of tradeoffs that invariably have been discussed to obscene lengths. Even “simple” workarounds often commit to implementation guarantees that language designers are hesitant to make until they’re certain it won’t box them into a corner in the future.
Put bluntly, anyone who asserts that a programming language design change is “simple” is only highlighting their own ignorance on the subject.
- nmilo 3y agoI didn't mean any offence when I called the change simple, though I do now see how it can be interpreted that way. When I call it simple it's because I am ignorant about programming language design changes, because, well, I don't really care. I'm not a PL designer. The change is simple to me because it: (a) seems arbitrary and easily changed, (b) solves a class of problem that I've never run into in other languages nor can ever really envision happening in a realistic scenario, and (c) if there are complex sets of tradeoffs involved in enabling this feature then they haven't been communicated well to the end-user at all. Especially with how bad the current state of affairs is, my calling the change simple should be a sign to the Rust team that if this really is the best possible decision for the language, they should put a clear statement in the compiler saying why. Because as it stands, from my end-user perspective, I still haven't seen a great reason why this shouldn't be implemented.
- ithkuil 3y agoAnother example: https://crates.io/crates/deepsize https://crates.io/crates/deepsize You can implement that for your types. Deepsize crate implements the trait for a few popular libraries. You can derive the trait in your structures and it will work for the few structures that happen to contain only your structures and the few hand picked structures supported by the deepsize crate. And then? What about the 99% of the other cases? Adding a trait impl is acceptable. Wrapping all the other types not much