Pre-Pre-RFC: Give trait methods a priority for resolving name clashes

No, it's never an upgrade. The priorities only come into play when there's a name clash. Today, a name clash of two trait methods is always a hard error. With my proposal, the ambiguity can be resolved in some cases.

This is about backwards compatibility. When the standard library adds a method, causing a name clash, that's not the user's fault. We shouldn't ask the user to fix errors introduced by the standard library.

2 Likes

I agree with you, but this comes with it's own cost; legibility and maintainability. If we force users to select the implementation that they are going to use explicitly, there will be lots and lots of grumbling about having to do the updates right now, but it will reduce technical debt going forwards. With priority sorting like this, it saves us in the short term (because everything keeps on working), but dramatically increases the cost in the long term as we need to remember that in some cases the name might not be what we expect it to be.

Put another way, let's assume that this proposal goes forwards as-is, and it's about 10 years in the future as we're shifting away from creating new code in rust, to doing a lot more maintenance work. You've now been thrust into a new project with a large code base, lots of dependencies, and OK documentation. You now want to add/remove/change some dependencies... and all of a sudden discover that while stuff compiles, it now behaves differently than you expected. Is it a runtime error? Is it a bug in the compiler? Running clippy, or turning on more warnings in rustc will turn this up, but how are you going to fix it? Search and replace would require knowledge that the compiler has, because the names are the exact same string, so regex won't work. A good IDE will probably help you figure it out, but now all that technical debt is landing in your lap. Worse, since this is an old project where you're kind of feeling your way around and not 100% sure you know why some choices were made, you're taking a large risk that you might break working code without being able to sort out how to fix it. So, you do what any sensible programmer does, and kick the can down the road... piling up even more technical debt. New programmers will eventually adopt a cargo cult mentality, because figuring out the dependencies properly will be a massive time suck, and not worth the effort1. Modifications will be very slow and error prone as you need to figure out which trait you actually want, and then force it's use (I'm thinking about different crates, their dependencies, and their dependencies, etc., etc., etc.).

Forcing fixes as close to the time that the code was written as possible is always more painful in the short term, but cheaper in the long term. And while I 100% agree with you that it's a horrible user experience to have to change your code through no fault of your own, the sooner it's done, the easier it is to actually do it.

1 I apologize that this sounds like a rant, but I've been on projects where we have to maintain stuff that should have been fixed earlier and the cost is now orders of magnitude higher simply because what would have been a small fix metastasized over time into a cancer that would have taken months to repair, and is now effectively too big to fix.

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.