feature request: record types with partially exported fields

Description

attached (M1) is an example of a situation, where haddock hides all fields of a record, just because one field is hidden. The result is that the other field is not shown in the documentation as well, even though it is exported.

As an example for why hiding certain fields of a record might make sense, consider M2. There we export two functions for decomposing T: f and g, whereas f is a class function that can be used for other datatypes as well, and g is a function specific to T. The ugly fT function is hidden from the user.

I'd wish myself a haddock output in which T would be shown in record style, but there would be a blank instead of fT or maybe something like "<hidden>".

Resetting priority. This makes the difference between the technique being usable or not. If none of the fields get documented then nobody can decipher the api.

My example is the tar package. I have a tar Entry type which is a record with a number of fields. I want to export record selectors so that user can do things like:

(fileEntry name content) { fileMode = executableFileMode }

However I do not want clients to be able to construct an Entry directly. We provide emptyEntry with default fields to be overridden. This lets us add new fields and guarantee that no client will break because they cannot mis-use the constructor by doing something like:

Entry blah blah blah ...

ie use it directly and then break when I add a field.

However if I do not export the constructor then the API docs do not mention any of the fields. It becomes just:

data Entry
Tar archive entry

So, how would we document a record where the constructor(s) are not exported. Well, when the constructor is exported it looks like:

Similarly, if I have a record type where all fields are exported, but the constructor itself is not (so that invariants can be enforced by the API), Haddock omits the fields from the documentation. If instead of

Type(field1,field2)

in the export list, I use

Type,field1,field2

Haddock would, of course, include the fields in the documentation but now they look as arbitrary functions, not as fields, which misses the point.