Status of inherent associated types

language design
1

Inherent associated types have been proposed for a very long time (7+ years). There is currently tracking issue #8995 for this, but nothing is listed as blocking. As far as I'm aware, this has never been implemented, but I also don't believe there should be anything major to hash out, given that associated consts are very much a thing (presumably some code could be shared?).

The reason I ask is because I recently wrote this code:

FormatDescription::Component(Component::Date(component::Date::Day(
    component::date::Day {
        // irrelevant details
    },
)))

…which is terrible to read. Admittedly, I have the component module in scope to avoid bringing in a ton of structs, but even without that it's still a bit wild. Consider the alternative if inherent associated types were a thing:

FormatDescription::Component::Date::Day(Day {
    // irrelevant details
})

Now the only repetition is for the enum → struct mapping, which is far better than before. The hierarchy is still clear, while repetition is minimal. I'd naturally prefer enum variant types as well, but that RFC hasn't even been merged yet.

So while I suppose it's a bit selfish, that's also the name of the game with most proposals :laughing: What can be done to help push this forward?

6 Likes
2

nothing is listed as blocking

IIRC, "inherent associated items types" is blocked on "lazy normalization" (#60471): https://github.com/rust-lang/rust/issues/8995#issuecomment-489308512

3

Why is this an issue for inherent associated types but not associated types on traits?

5 Likes
4

I would also love to hear more detail about why this is blocked on lazy normalization.

5

cc the lang team members to see if this is even still the case? @josh @nikomatsakis @cramertj @pnkfelix @scottmcm

No idea if who's active on internals and who's not

2 Likes
6

If the RFC's approved but it's not implemented in nightly, you'd probably have better luck asking T-compiler people (perhaps on zulip).

I'm usually watching Internals, but have no idea what is or isn't easy in the implemented resolution engines.

7

In that case, pinging all T-compiler members who have not already been pinged!

@wesleywiser @davidtwco @eddyb @ekuber @lcnr @matthewjasper @nagisa @oli-obk @petrochenkov @varkor

Sorry for the mass-pings — just that some of us are curious about the status :slightly_smiling_face:

If there's no response I'll probably hop on Zulip to see if someone can stick their head over our way.

8

while we may run into lazy normalization problems quickly, it should be totally fine to add associated types to inherent impls behind a feature gate. Considering that we already have most of the logic for trait impls, I don't see any inherent (heh) problems with this.

2 Likes
9

Also, would it be feasible to add a few special cases and start stabilizing them, even if the broader case is still blocked on lazy normalization?

By special cases, I'm thinking "Only types defined in child crates are allowed, and maybe non-generic types in the current crate". That way you don't risk running into cycle errors.

10

Definitely. If we can come up with a sane subset, we should stabilize it. If not, we may still stabilize it and just have really weird errors in the cases where lazy normalization is needed.

I don't think I'll have the capacity to implement this in the next few months, but I'd be happy to mentor it.

8 Likes
11

(sent a PM)

12

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