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.