Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documenting rules for when type inference can solve for indices #94

Open
ExpHP opened this issue Mar 21, 2018 · 1 comment
Open

Documenting rules for when type inference can solve for indices #94

ExpHP opened this issue Mar 21, 2018 · 1 comment
Assignees

Comments

@ExpHP
Copy link
Collaborator

ExpHP commented Mar 21, 2018

I do a small bit of this in the coproduct embed PR, but I think there should be more:

There should be one central piece of documentation (which other methods can link to) describing the Index technique commonly used in frunk, describing how:

  • Users should generally not worry about Index type parameters. Even when using turbofish syntax (once available), these should generally be left to type inference using _.
  • Generally speaking, type inference can solve for the indices whenever there is a unique solution.
  • This means that methods like hlist's pluck and coproduct's inject succeed when the type appears exactly once in the HList/coproduct.

It should also explain workarounds for when type inference fails:

  • The preferred method, whenever possible, should be to use newtypes in your HList/coproduct, so that all of the types are distinct. (@Centril, @lloydmeta do you agree?)
  • As a last resort, indices can be specified explicitly, but I'm not sure that the docs should be suggesting this course of action quite yet as they feel mostly like an implementation detail. (maybe once reified indices are added, if I ever get to that; I still need to get more experience with them first in funky)
@Centril
Copy link
Collaborator

Centril commented Mar 21, 2018

Users should generally not worry about Index type parameters. Even when using turbofish syntax (once available), these should generally be left to type inference using _.

Agreed; Hopefully you won't even need to specify _ in the future with some sort of "partial turbofish" (see my RFC on this -- rust-lang/rfcs#2176) mechanism in the language itself.

I also agree with everything else you said.

@ExpHP ExpHP self-assigned this Mar 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants