Error in interaction between associated_type_defaults and associated_type_bounds

I'm not sure if this is an issue with the current implementation of associated_type_defaults or a larger problem with the RFC. Here's the example:

#![feature(associated_type_defaults, associated_type_bounds)]

trait View {
    type Deserializers: Deserializer<Item = Self::RequestParams>;
    type RequestParams = DefaultRequestParams;

struct DefaultRequestParams;

trait Deserializer {
    type Item;
    fn deserialize(r: impl Read) -> Self::Item;

And the error:

error[E0271]: type mismatch resolving `<<Self as View>::Deserializers as Deserializer>::Item == DefaultRequestParams`
  --> src\
14 | trait View {
   | -------------- required by `View`
17 |     type Deserializers: Deserializer<Item = Self::RequestParams>;
   |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `DefaultRequestParams`, found associated type
   = note:       expected struct `DefaultRequestParams`
           found associated type `<Self as View>::RequestParams`
   = help: consider constraining the associated type `<Self as View>::RequestParams` to `DefaultRequestParams`
   = note: for more information, visit

In this case I want the bound to be the as-of-yet-unspecified type View::RequestParams not the concrete default type. This compiles and works without the default.

Is there another way to specify that the type in the bound should be View::RequestParams or is this case currently unimplemented/impossible?

(you don't need associated_type_bounds here by the way, that's an unrelated feature)

This seems like a bug. The projection Self::RequestParams should not be normalized successfully there.

I think this happens because of the defaults validation code I added. It will replace projections to defaulted types to check that all specified defaults are valid.

Thanks, I've created an issue here.

1 Like

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