b2015792

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Ask a newtype's field for unExample rather than a prefix

HsPrefixNaming held every field to starting with the name of its type, which
is the one thing the field of a newtype cannot be called. unWorkerName cannot
carry the whole of WorkerName in front of it and stay that spelling, so the
rule reported every newtype accessor written the way the ecosystem writes
them, and offered nothing to write instead.

A prefix on a field says which type it belongs to, which is worth saying
because the fields of a data type have to be told apart from one another. A
newtype has exactly one field, so there is nothing to tell it apart from and
the prefix would only repeat what the declaration already says. The name says
the useful thing instead, that applying it undoes the wrapper.

So a newtype's field is now held to exactly unExample, and the finding names
that spelling rather than describing a prefix. NameRole gains a third
constructor, because the three roles are the three different things a name is
held to. Which role a field gets is decided in introducedBy, the only place
that can see whether the declaration is a newtype: the field itself is written
the same either way.

A rule that ships has to hold here, and this one found twelve newtypes in this
repository written the old way, so they are renamed with it.

Total

7s

Created 1 week ago Started 1 week ago Finished 1 week ago

Timeline