#rust-lang

ah. but knowing that relies on knowing about the impls for Assoc

You’re not wrong

maybe to put it differently: i think that new bridge impls can cause open sets to become closed

(or new impls in general)

That’s interesting

I guess I’d like to look at an example of that

woboats_: https://gist.github.com/aturon/dece5ba1baf94262...

woboats_: the impl on line 9 determines whether the Foo impl is closed or not

oh gosh

What if we just stop letting you specialize associated types

That’s always seemed like a very wonky part of the system

Well

13 shouldn’t be allowed without 9

hm true

But there are no other local impls of Foo so maybe it should be

it's certainly weird

But that impl would conflict with literally any other impl, right?

I guess not a blanket impl for T

*default’d blanket impl

yeah

re: why let you specialize assoc types, https://github.com/rust-lang/rfcs/pull/1210#iss...

it might be worth revisiting; it is pretty subtle stuff

(there are a couple comments starting at the one linked)

i feel pretty confident that if we don't let you, it'll be seen as a frustrating limitation over time

use two traits though

the only case where I clearly have wanted it, what I *really* wanted was impl Trait in traits

impl Trait in traits is a good example though

where if you override any such impl, chances are good you want to override the hidden type as well

which has basically the same problems

I see

Well its not as much of a problem because you can’t project an impl Trait

woboats_: there's some desire to be able to refer to the type for impl Trait

which i *think* would enable similar examples to my original gist