---
title: 2025-11-25 - impl subtrait via supertrait
tags: ["T-Types", "minutes"]
discussion: https://rust-lang.zulipchat.com/#narrow/channel/326132-t-types.2Fmeetings/topic/2025-11-25.20impl.20subtrait.20via.20supertrait/with/560204338
url: https://hackmd.io/pwSkzuYkStaQK59QfUwaIA
---
# 2025-11-25 - impl subtrait via supertrait

Example gist: https://gist.github.com/rust-play/0ab82539ad83b447884beff4df22b17f

## Background

Amanieu: The `write!` macro in std is a terrible hack. It takes the writer argument and just calls `write_fmt`. It doesn't do any checking. Depends on what's in scope to figure out what to call. We're trying to fix that over edition.

Josh: Depending on which trait you use (fmt::Write or io::Write), each has a fixed error. If you want to write into a `String` or `Vec` those don't need an error. We'd like to make those cases infallible. I've added a change to the compiler so that `Result<(), !>` will not trigger `must_use`. We're trying to create a new trait for `write!` that has an associated `Error` type.

Josh: This is where types team comes in. We want to add a mechanism so that both `io::Write` and `fmt::Write` traits could use this trait without breaking the universe. This ties into the auto impl mechanism. If I have this subtrait but I don't already explicitly implement this supertrait, use this auto impl of this supertrait.

Amanieu: Blanket impl doesn't work because we want to use the explicit implementation. We want to provide a default blanket impl that can be overridden.

Josh: We're hoping this doesn't turn off specialization.

Jack: You want to switch the `write!` macro too, right?

Josh: Yes, we'll add a new `write` and then over an edition switch wmich write macro is in the prelude.

Josh: We'd like `fmt::Write` and `io::Write` to say "if you don't have the impl of `WriteFmt` trait, here's an impl you can use". There are 2 features we'd need: (1) auto impl mechanism and (2) for compatibility in order to say what that associated Error type is, we'd love to be able to have associated type to be `type Error = impl Trait`

Jack: Is the only difference between these two traits (Write and WriteFmt) the Error type alias?

Josh: the diff between `std::fmt::Write` and `WriteFmt` trait is that the new one has the associated Error type and methods that return it. The `io::Write` has a lot of other methods.

Jack: You could add an associated type to the existing trait with a default (which would be the existing error type). That's already in the compiler. Making a default type that's an opaque type might be interesting. But it might work. That seems more simple, have you thought about it?

Josh: We did think about a possibility of adding backwards-compatibly an associated type to `io::Write` and `fmt::Write`. If we could, that would be great. In general, implement supertrait in subtrait is something we're interested in many other areas. But putting that aside: we *can* (over an edition) break the `write!` macro. But traits are traits across the entire graph of dependencies regardless the edition. We could add a new `io::Write` but we want to be compatible and have a single `io::Write` type.

Josh: If we did that, suppose someone wanted to change that and implement io::Write's error into something like Infallible. Anyone can take that result, store it into `io::Result` and that doesn't work here. The reason we wanted it to be a parent trait is that the ??.

Amanieu: The specific breaking change we want to avoid: in the std the `Vec<u8>` implements `io::Write`. And `write_str` returns an `io::Error`. We want the `write!` macro to implement on `Vec<u8>` and have that error be infallible.

Jack: I still don't see why having the associated error type is breaking.

Josh: Every existing user of io::Write has the right to run the associated write function and get the resulting error.

Jack: Every case after that would still have that.

Josh: Right. But if you add an asssociated type, that doesn't allow you `write_fmt` method to change to return that associated type because that would break the user. We could add a new method.

lcnr: If we add associated type to fmt::write trait. What if in older editions `T: Write` gets lowered and in the future edition you remove the default.

Amanieu: It's also for method resolution in general. If you have a type currently that implements `fmt_write` if you call ??. It would be a breaking change for a crate that provides implementation for fmt_write. We're trying to do this for std types like Vec and String.

Josh: We want to make it so that every user using `io::Write` can call `write_fmt` and get the `io::Error` they expect. But using the new write! macro they get the associated type. The thing we're relying on is: in the broader crates.io impl, if the default impl is an opaque impl `Into<io::Error>` it's not a breaking change. 80% callers would be fine because they `?` or `unwrap` it and the rest would call `into()`.

Josh: Going from an opaque type to a concrete type that implements the methods of the opaque type, that shouldn't be a breaking change. Callers can do all the things they could do before.

Jack: So the key bit here that you want to change the error type for existing types.

Josh: Yes, we want to change the Error type for things that currently implement io::Write without breaking callers on io::Write so it needs to be a new trait.

Jack: Does anyone else have clarifying questions?

(no)

Jack: Looking at the gist. There are 3 different pieces to think about. (1) auto impl write format (2) priority low (3) `type Error = impl Into<Error>`

boxy:

lcnr: RPITIT exists that has this exact thing

Jack: it's not ..

boxy: It's not really an impl, it's a trait implementation with a bunch of defaults and adding an automatic empty default.

Jack: From the types side this is not that difficult. The desugaring happens at the ?? level. You need to have some way to ensure that if there's another impl that we don't add this. But you can place enough restrictions on the language side where this becomes trivial. It would be interesting but not that bad. If you write `impl Write for _` you get also `impl WriteFmt for _`.

Amanieu: It's basically the same as blanket impl except that it doesn't prevent you from adding more on top of it without running into coherence rules.

Jack: You could do that. There are other ways too.

Jack: My biggest concern is the `priority[low]`. That might not be attainable soon. Also if you start with enough restrictions, it would be backwards-compatible to add in priority low later on.

Jack: The only one that's a little weird is `impl Write for &mut W` (https://doc.rust-lang.org/stable/std/fmt/trait.Write.html#impl-Write-for-%26mut+W)

Jack: I'd like to see some examples for where you'd like this auto impl not to apply and where would you expect it to apply. When a user writes an impl of `WriteFmt`, when would this auto impl apply and when it wouldn't.

Josh: If the user writes their own impl of WriteFmt, this should never apply. IT should only apply when the user doesn't write their own impl of WriteFmt.

Josh: We were thinking of this in concrete types. Where you might choose to add an impl of WriteFmt trait later. But doing things like "for everything that implements this implement io::Write and then for everything that implements *that* implement fmt".

Josh: If the first step would only be on concrete types or parametrised ?? but not on blanket impl, that would be acceptable.

boxy: We do have something similar syntactically with auto traits.

Jack: I wanted to delay that discussion. There's too bikesheddy for now.

Josh:

important:

impl WriteFmt for ConcreteType
impl WriteFmt for GenericType<T>

Not important right away:

impl<T: Foo> WriteFmt for T 

Jack: Counterexample

struct UserTy<T, U>;
impl<T, U> WriteFmt for UserTy<T, U> {}
impl<T> Write for UserTy<T, ()> {}

// Does this get generated:
impl<T> WriteFmt for UserTy<T, ()> {}

lcnr: Looking at your example, the example what would be very hard to support is this:

struct UserTy<T>(T);
impl WriteFmt for UserTy<u32> {}
impl Write for UserTy<i32> {}

// Does this get generated:
impl WriteFmt for UserTy<i32> {}

Jack: If you make this a syntactic check, then it's okay and on the type side is fine. If you want anything deeper, you'll end up with a lot of issues. I'm happy to do another meeting on this if we prepare a doc ahead of time and properly schedule it out.

Josh: Thank you for taking about this and doing it much sooner than we expected.

Jack: That's why I wanted to do this soon -- to have the vibe discussion. But if want to go deeper, let's get the design doc going and schedule a proper meeting.

lcnr: You've got the auto trait type that's got some edge cases that won't work well. The priority when emitting impls is hard to implement.

Josh: That would be really nice if we could have a solution to that. But if you told us that'd be painful to do, we could rely on the fact that nobody in practice implements both `io::Write` and `fmt::Write` on the same type. We'd have to check the ecosystem, but nothing in the std does this. So if we said you can only implement only one, that might not be the end of the world.

lcnr: If it happens during lowering without ever doing any type related traits or whatever, that's a bit ugly but it's not doing anything horrible with the type system. That's more of a language question.

Josh: This is an experiment where several of us on libs-api and lang, we often end up coming to types where in the course of something else we had to end up with types. But we rarely talk to types earlier. If you see another way of solving this or design constraints to apply to this to make it wildly easier in the type system, give us those constraints and we'll see if we can come up with those constraints.

lcnr: If you want to do this in types properly to emit the implementations, that's something we don't do a lot currently.

lcnr: If you want to use an overlap check, we need to know all the impls that exist.

Josh: Yeah, you're suddenly turn into "you're allowed overlapping impls as long as none of them is auto impl".

lcnr: The compiler also needs to prove this guarantee. You could imagine having WriteFmt and io::Write impl which can disagree over the arguments

Josh: This is where we'd love to receive any restrictions (e.g. to make this really obvious to the compiler). It would be fine if the only case you could do is some type (possibly with a generic type parameter) implements io::Write

Josh: If we said the only way this works is if your impl WriteFmt syntactically matches module what you call these things, then you're effectively saying "if it syntactically matches such that it has textually the same bounds, then we can make it work; and otherwise we can't instantly tell and therefore we can't do it now but might in the future". That would be acceptable.

Josh: We'd use it in the standard library at first. And we could let the ecosystem use it under these restrictions. That would still be incredibly valuable. Most people want the `ConcreteType` or `SimpleGenericType<T>`

lcnr: That one feels easy enough. It doesn't touch the type system.

Josh: If you can spell out which restrictions makes it easy of you.

lcnr: The type constructur must be a rigid type (no type parameters) that's unique

Josh: Right, you can't make this to be a GAT (generic associated type).

lcnr: You need a type that's only equal to itself assuming the generic parameters match.

Josh: If the restriction is "don't let this touch GATs", that's fine

lcnr: Doesn't have to be a GAT, it can also be `<T as Trait>::Assoc`.

Josh: I can live with that for now, but I'd love to know where on the "this is hard" scale is.

Josh: Thank you everyone.