.lock file for method resolution.

The problem with methods in rust is that basically adding any methods in any way is technically™ a breaking change, since adding a method can either cause ambiguity or a different method to be resolved at the call site.

But what if, when compiling, the compiler outputted a file, which basically says "ah yes, that method call is resolved to this method", then compiler can prioritize the resolution in the .lock file over what actually would be happening.

Now, this has multiple problems (like changing the .lock file affects code in potentially very surprising ways) and would probably be hard to do, but still, would be cool to fix the problem...

A slightly less unhinged way would be to have either an annotation or another generated file, which says in which version a method was added, so that when compiling reverse-dependencies compiler could ignore the methods that were introduced in versions newer than the expected one.

(still potentially a breaking change with merging cargo features, but well, we could try accounting for that too...)

.lock file for method resolution.

The problem with methods in rust is that basically adding any methods in any way is technically™ a breaking change, since adding a method can either cause ambiguity or a different method to be resolved at the call site.

But what if, when compiling, the compiler outputted a file, which basically says "ah yes, that method call is resolved to this method", then compiler can prioritize the resolution in the .lock file over what actually would be happening.

Now, this has multiple problems (like changing the .lock file affects code in potentially very surprising ways) and would probably be hard to do, but still, would be cool to fix the problem...