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.
Your proposal might work but then the user won’t have the compile-time guarantee that they can’t try to write to a read-only filesystem, since the capability will be queried at run-time.
> Make the file system itself a trait, with implementations for read-only and read/write
Those are separate concrete implementations between read-only and read-write; a write operation can be implemented on the read-write implementation only.
So… you lose the ability to have a generic parameter which implements the trait. You need to know the concrete implementation in order to know if there’s a write method, for example.
It doesn't sound like they're making multiple implementations that can write? If they were, they could make a trait for a Writable fs.
But from their description it sounded like exactly two concrete implementations, one read-only, one read-write. If you want to share code or implementations, there's lots of ways still. For example, if the read-write filesystem implementation is a superset of the read-only, put a read-only struct inside the read-write.
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...
For those who are new to the concept, in a nutshell, CGP allows you to bypass the coherence restrictions in traits/typeclasses, and define multiple overlapping and generic implementations for each CGP trait. As a consequence, when you define a new type, you need to specifically choose an implementation to be used with that type. This is called a wiring step, where you choose the provider implementations for your context.
On the surface, this addition doesn't seem significant. However, it opens up a world of possibilities for enabling powerful design patterns that are based on trait implementations that are named, generic, and overlappable. One of the greatest strengths of CGP is to enable safe, zero-cost, compile-time dispatching through the trait system to accomplish the things that in OOP would typically require dynamic dispatch with runtime errors.
As of 2025, CGP remains in its early stages of development. While promising, it still has several rough edges, particularly in areas such as documentation, tooling, debugging techniques, community support, and ecosystem maturity.
...
At this stage, CGP is best suited for early adopters and potential contributors who are willing to experiment and help shape its future.
Clever work. I'm glad to see Rust is at the AbstractSingletonProxyFactoryBean stage of its lifecycle.
Look: patterns like this might unblock people locally but they point to a gap between what people want to say and what the base language allows them to express. In the long term, it's better to expand the language than devise increasingly heroic workarounds for syntactic sclerosis.
> 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
Note that negative traits are not for "this trait is not implemented" (i.e. a missing `impl Trait for Type`) but instead for "this trait is guaranteed to not be implemented" (i.e. `impl !Trait for Type`)
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.
Sometimes the simpler approach is better.
Your proposal might work but then the user won’t have the compile-time guarantee that they can’t try to write to a read-only filesystem, since the capability will be queried at run-time.
I may be misunderstanding, but
> Make the file system itself a trait, with implementations for read-only and read/write
Those are separate concrete implementations between read-only and read-write; a write operation can be implemented on the read-write implementation only.
If the filesystem is a trait which has a read and write method. Your concrete implementations have to implement both.
So... Don't give the trait methods that don't apply to every member of the trait. Only implement write methods on the concrete Write implementation.
So… you lose the ability to have a generic parameter which implements the trait. You need to know the concrete implementation in order to know if there’s a write method, for example.
It doesn't sound like they're making multiple implementations that can write? If they were, they could make a trait for a Writable fs.
But from their description it sounded like exactly two concrete implementations, one read-only, one read-write. If you want to share code or implementations, there's lots of ways still. For example, if the read-write filesystem implementation is a superset of the read-only, put a read-only struct inside the read-write.
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...
For those who are new to the concept, in a nutshell, CGP allows you to bypass the coherence restrictions in traits/typeclasses, and define multiple overlapping and generic implementations for each CGP trait. As a consequence, when you define a new type, you need to specifically choose an implementation to be used with that type. This is called a wiring step, where you choose the provider implementations for your context.
On the surface, this addition doesn't seem significant. However, it opens up a world of possibilities for enabling powerful design patterns that are based on trait implementations that are named, generic, and overlappable. One of the greatest strengths of CGP is to enable safe, zero-cost, compile-time dispatching through the trait system to accomplish the things that in OOP would typically require dynamic dispatch with runtime errors.
For anyone interested in reading about CGP in Rust, here is the website:
https://contextgeneric.dev/
Just a FYI from their main page:
As of 2025, CGP remains in its early stages of development. While promising, it still has several rough edges, particularly in areas such as documentation, tooling, debugging techniques, community support, and ecosystem maturity.
...
At this stage, CGP is best suited for early adopters and potential contributors who are willing to experiment and help shape its future.
Clever work. I'm glad to see Rust is at the AbstractSingletonProxyFactoryBean stage of its lifecycle.
Look: patterns like this might unblock people locally but they point to a gap between what people want to say and what the base language allows them to express. In the long term, it's better to expand the language than devise increasingly heroic workarounds for syntactic sclerosis.
> 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
The length Rust programmers will go to avoid writing `Box<dyn Trait>` is astonishing. The heap is there for a reason :)
The performance hit you take for doing dynamic dispatch is real and measurable. It's a no-go if you're in a performance sensitive part of your app.
I write rust for no_std embedded devices and I just use stack_dst for this :)
Of course you‘re right if you can‘t alloc, you can‘t use Box or similar stuff.
Also you can avoid a lot of performance hits if you just implement most stuff on the dyn Trait directly!
Sure but most code paths are not hot. This is definitely premature optimization at the expense of everything else.
I’m guilty of this… I’ve doing using Rust for 10 years, and I’ve only ever used `Box<dyn>` maybe 4 times all up.
.. yep, I’ll try everything before introducing virtual functions just out of warm fuzzies rather than anything measurable
can't it be solved by negative traits?
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)?
Note that negative traits are not for "this trait is not implemented" (i.e. a missing `impl Trait for Type`) but instead for "this trait is guaranteed to not be implemented" (i.e. `impl !Trait for Type`)
aka that's what read-only is for write?
[dead]
[dead]
[dead]