Skip to content
This repository has been archived by the owner on May 20, 2020. It is now read-only.

Dynamic Monomorphization of Docs #165

Open
Havvy opened this issue Aug 21, 2017 · 1 comment
Open

Dynamic Monomorphization of Docs #165

Havvy opened this issue Aug 21, 2017 · 1 comment

Comments

@Havvy
Copy link

Havvy commented Aug 21, 2017

Somehow, have a way of letting a user put in their own types for the generics that another type or trait contains. For example, if I had two types, ::my_crate::Address, and ::my_crate::Home, and I wanted to see what the more concrete methods on HashMap<Address, Home> are, I should be able to do so.

This probably needs both frontend and backend work because we want to know what trait bounds that the concrete types have.

This is not going to be easy. Consider the following examples and questions:

  1. Consider that Home does not impl Eq, then we do not want to show impl Eq for HashMap<Address, Home, S> where S: BuildHasher> since that would be wrong.

  2. Consider, instead, that Home is generic over HouseStyle, so it is Home<HS> where HS : HouseStyle. We'd want the documentation to show struct HashMap<Address, Home<HS>, S = RandomState> where HS: HouseStyle which includes the trait bound for Home. Furthermore, if we assume there's an impl<HS> Eq for Home<HS> where HS: Eq, then the Eq impl for the HashMap should be impl Eq for HashMap<Address, Home<HS>, S> where S: BuildHasher, HS: Eq>.

  3. Consider instead we want to show the docs for HashMap<K, V, S = RandomState> where V: Eq basically replacing V with V where V: Eq Consider a trait impl that depends on K impling some trait that is generic on V. How do we do this? Do we even allow this? (Probably not initially)

On the UX side, how do you make it easy to choose the correct type? You cannot really take types from your own crate in the stdlib docs unless those docs are also available in your own crate documentation, that you build, so would every crate would need its own copy of the libcore and libstd docs? How do you make it so that you can further specialize types that are also generic? E.g. in the second example, what if you want to replace HS with BlockHouseStyle? And what if you want to go back to being generic by one layer? Does the back button do that? And what does the UI for monomorphizing even look like in the first place?

But if we can get this working, it would be a huge boon to teaching how to use generics types to people. Instead of just linking to Option we could link to docs for Option and show what can be done with that.

@mjkillough
Copy link
Contributor

I think this would be useful even without the 'dynamic' bit: see rust-lang/rust#32077.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants