Report custom types with 1 constructor and without any data

[jfmengels]

What the rule should do:

Report when a custom type does not hold any data.

What problems does it solve:

I found code that started like

type A = B | C Data

but got trimmed down because of elm-review-unused rules to type A = B, and that's where these rules stop reporting anything.
The model still has a field of type A and there is code that uses it

type alias Model = { a : A, ... }

view model =
  div []
    [ case model.a of
        B -> text "something"
    , if model.a /= B then
        text "not B"
      else
        text "B"
    ]

By reporting A and telling the user to remove it, we will force them to remove the a field and to simplify the different branching that happens in the code for no reason.

Example of things the rule would report:

type A = B

Example of things the rule would not report:

When the type is used in the stead of a phantom type variable.

type Thing = Thing
type OtherThing = OtherThing
type A a = A String

function1 : A Thing -> String
function2 : A OtherThing -> String

Such custom types are typical use-cases for phantom types.

I am wondering whether we should report these types when they're exposed as part of the module. I would like to think that yes, unless they are used in the stead of a phantom type variable somewhere in this file, but I wonder whether there are edge cases where that would be ok.

When (not) to enable this rule:

I am looking for:

• A good rule name
• To know in which package(s) this would fit best. I feel like it would fit in elm-review-unused, as it's kind of a useless thing. What do you think?

[MartinSStewart]

Example of things the rule would not report:
When the type is used in the stead of a phantom type variable.

I think it should report an error here and explain that if you are using this as a phantom type, change type Thing = Thing to type Thing = Thing Never

[jfmengels]

Oh that's interesting! That's a good way of marking it as a phantom type for elm-review to know. I remember you talking about that before.

I am now thinking that we should probably also never expose the constructors of a type that contains Never in its sole constructor (or constructors? 🤔), but that would be a different rule I think.

[MartinSStewart]

Yeah, making sure the constructor of type Thing = Thing Never isn't exposed makes sense as well.

[jfmengels]

I found a use-case where a data-less constructor is useful.

-- Made opaque and created only for admins
type ProofOfAdminPermissions = ProofOfAdminPermissions

type Role
  = Admin ProofOfAdminPermissions
  | User

deleteDatabase : Proof -> Cmd Msg
deleteDatabase _ = ...

Here, ProofOfAdminPermissions does not hold any data, but does "contain" (represent) the indirect data that the user has access to some functions.

Browser.Navigation.Key is another example of that. I thought it contained data, but it apparently doesn't.

These cases are rare, but I am less convinced that this rule is a good idea in all cases.

Of course, it is possible to recommend they be changed to type ProofOfAdminPermissions = ProofOfAdminPermissions (), just like we would recommend to add Never. But that could be something NoUnused.CustomTypeConstructorArgs may want to report 🤔

I wonder if there is some other way to detect when types become like type A = B.