Skip to content

Avoid _ inner parameter names in higher-kinded types #950

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.

Sign up for GitHub

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

Closed
wants to merge 2 commits into from
Closed

Avoid _ inner parameter names in higher-kinded types #950

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
75eb6aa
Avoid `_` inner parameter names in higher-kinded types
Atry Dec 14, 2017
f89e614
Use scala kind `*[*]` instead of pseudocode `*=>*`
Atry Dec 18, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions _style/naming-conventions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -307,24 +307,26 @@ used in place of a longer, descriptive name:
Higher-kinds are theoretically no different from regular type parameters
(except that their
[kind](http://en.wikipedia.org/wiki/Kind_(type_theory)) is at least
`*=>*` rather than simply `*`). The naming conventions are generally
`*[*]` rather than simply `*`). The naming conventions are generally
similar, however it is preferred to use a descriptive name rather than a
single letter, for clarity:
single letter, for clarity. The inner parameter names should be `*` or
other descriptive names, instead of `_`, to avoid confusion with
existential types:

class HigherOrderMap[Key[_], Value[_]] { ... }
class HigherOrderMap[Key[*], Value[*]] { ... }

The single letter form is (sometimes) acceptable for fundamental concepts
used throughout a codebase, such as `F[_]` for Functor and `M[_]` for
used throughout a codebase, such as `F[*]` for Functor and `M[*]` for
Monad.

In such cases, the fundamental concept should be something well known
and understood to the team, or have tertiary evidence, such as the
following:

def doSomething[M[_]: Monad](m: M[Int]) = ...
def doSomething[M[*]: Monad](m: M[Int]) = ...

Here, the type bound `: Monad` offers the necessary evidence to inform
the reader that `M[_]` is the type of the Monad.
the reader that `M[*]` is the type of the Monad.

## Annotations

Expand Down