Overloaded record fields meta-ticket
This is a meta-ticket covering the ongoing work on The Records Problem related to
RecordDotSyntax, after I discussed the current state of things with @simonpj. See also issues labelled OverloadedRecordFields and the overloaded-record-fields wiki page.
The following pieces have accepted GHC proposals and their implementations are in flight:
RecordDotSyntax(#18599, ghc-proposals#282). This somewhat depends on
setField, although it could be implemented independently using whatever
setFieldhappens to be in scope. Being implemented by @shayne-fletcher-da on branch
Issues for the future:
Consider whether the
DuplicateRecordFieldsspecification can be simplified, as the circumstances in which ambiguous field selectors are accepted are somwhat unclear. See ghc-proposals#366 for a proposal to make the rules more restrictive (and ghc-proposals#84 for an earlier, dormant attempt). See also ghc-proposals#310.
Consider whether the
DuplicateRecordFieldsimplementation can be simplified, rather than doing some field name resolution in the renamer and some in the typechecker. We previously considered moving everything to the typechecker (see #15149 (closed), #15277). But if the specification were simplified enough to avoid anything type-directed, it might be possible to do everything in the renamer instead.
Resolve issues around representing
DuplicateRecordFieldsin Template Haskell (#14848, #17381, #17551). This primarily requires investigation of the best way to represent field names in the TH AST, ideally a way that avoids losing information when it is known which datatype contains the field.
Refactor dark corners of the renamer, in particular the unsatisfactory representation of
GlobalRdrElt(i.e. the fact that mangled selector
Names are used to represent fields, so one must be very careful not to use the
OccNameas if it were meaningful to users). Avoid #13352, perhaps by reducing the reliance on name-mangling? Investigate #16745.
Warnings around partial fields. See #18650.
... what else?