Ada does this too

Ada does this too

Posted Feb 13, 2025 8:00 UTC (Thu) by khim (subscriber, #9252)
In reply to: Ada does this too by NYKevin
Parent article: Maintainer opinions on Rust-for-Linux

> We do not want to recreate the C++ situation where all the types match, but then something blows up in monomorphization.

Well… it's like Greenspun's tenth rule. Rust didn't want to “recreate the C++ situation” and as a result it just made bad, non-functional copy.

As you saw “something blows up in monomorphization” is already possible, only it's unreliable, had bad diagnosis and in all aspects worse that C++.

Perfect is enemy of good and this story is great illustration IMNSHO.

> Outside of those special cases (which typically make heavy use of unsafe), the general expectation is that if a type matches a given set of trait bounds, then I can use it as such.

Yeah. A great/awful property which works nicely, most of the time, but falls to pieces when you really try to push.

> This is useful for pedagogical reasons, but it is also just a heck of a lot more convenient.

It's convenient till you need to write 566 methods instead of 12. At this point it becomes both a PITA and compilation times skyrocket.

> But trait bounds are more than just a convenient linting service. They are a semver promise.

But when these bounds are not there from the beginning they are becoming more of “semver rejection”.

That's why we still have no support for lending iterator in for. And said lending iterator was a showcase of GATs four years ago.

At some point you have to accept that your language couldn't give you perfect solution and can only give you good one.

Rust developers haven't accepted that yet and thus we don't have solutions for many issues at all.

And when choice is between “that's impossible” and “that's possible, but with caveats” practical people pick the latter option.

> Under Rust as it currently exists, that is not a compatibility break, and it would be very bad if it was.

Except, as you have already demonstrated, that's not true, this capability already exist in Rust – and “perfect solutions” don't exist… after 10 years of development.

Maybe it time to accept the fact that “perfect solutions” are not always feasible.

> Nobody is actually going to do that, so we're simply not going to be semver compliant in this hypothetical.

That's already a reality, Rust is already like this. It's time to just accept that.

---

to post comments