In Haskell, we call this problem "overlapping instances," and can be allowed with an optional compiler flag. Nevertheless, I try to avoid using it, because of the potential for unforeseen consequences and reduced clarity in which code is actually being run.
In this use case, my instinct tells me that trait specialization is the wrong tool for the job. The author is trying to dispatch different functions based on a flag set in the caller. I can think of two more elegant ways to do this:
* Make the file system itself a trait, with implementations for read-only and read/write. Pass the concrete implementation as a parameter to the function using it.
* Store the capabilities as a variable in the file system object and query it at runtime. This can be done with an if.
With Context-Generic Programming (CGP), there is a way to get around the coherence restriction through a provider trait, and have overlapping implementations in safe, stable Rust. I have a proof of concept implementation of example in the article here: https://gist.github.com/soareschen/d37d74b26ecd0709517a80a3f...
> Lastly, the unstable specialization feature also deals with lifetimes, which as I mentioned is the feature's biggest obstacle on the way to stabilization.
The issue is really that `specialization` *has* to deal with lifetimes, even when there is apparently none. The example core with `Read` and `Read + Seek` also suffers from lifetime issues: some type could implement `Seek` depending on some lifetime and this would make your specialization unsound. For this reason `min_specialization` does not accept your specialization.
Isn’t it possible to just use trait objects for this?
You can have default implementation for some methods and implementors of the trait can specialise.
Specifically, you can have couple functions that takes a type that implements some stuff (different based on the wanted specialisation) and gives you a trait object.
This should be simpler and should have better compile time than doing macros or adding more generics
8 comments
[ 2.8 ms ] story [ 21.6 ms ] threadIn this use case, my instinct tells me that trait specialization is the wrong tool for the job. The author is trying to dispatch different functions based on a flag set in the caller. I can think of two more elegant ways to do this:
* Make the file system itself a trait, with implementations for read-only and read/write. Pass the concrete implementation as a parameter to the function using it.
* Store the capabilities as a variable in the file system object and query it at runtime. This can be done with an if.
Sometimes the simpler approach is better.
isn't the problem that rw is still r, so passes checks for both?
can't you make one rw and the other r(-w)?
The issue is really that `specialization` *has* to deal with lifetimes, even when there is apparently none. The example core with `Read` and `Read + Seek` also suffers from lifetime issues: some type could implement `Seek` depending on some lifetime and this would make your specialization unsound. For this reason `min_specialization` does not accept your specialization.
You can have default implementation for some methods and implementors of the trait can specialise.
Specifically, you can have couple functions that takes a type that implements some stuff (different based on the wanted specialisation) and gives you a trait object.
This should be simpler and should have better compile time than doing macros or adding more generics