Depending on a record's field names / field selectors makes the generated code brittle. For example:
When the record you're using with prairie shares field names with another record (e.g. you're using deriveEsqueletoRecord with the default settings), the code generated by mkRecord fails to compile because the record field accessors become ambiguous:
src/Test.hs:(32,1)-(36,3): error:
Ambiguous occurrence 'Test.foo'
It could refer to
either the field 'foo' of record 'Test',
defined at src/Test.hs:27:5
or the field 'foo' of record 'SqlMaybeTest',
defined at src/Test.hs:32:1
or the field 'foo' of record 'SqlTest',
defined at src/Test.hs:32:1
That's with -XDuplicateRecordFields enabled already.
When you have -XNoFieldSelectors enabled, the field selectors are not in scope:
src/Test.hs:(32,1)-(36,3): error: [GHC-76037]
Not in scope:
'Test.foo'
Suggested fixes:
• Notice that 'Test.foo' is a field selector belonging to the types
'Test', 'SqlMaybeTest', 'SqlTest' that has been suppressed by
NoFieldSelectors.
If it's possible to use the fields by pattern matching / constructing them with positional arguments on the record's data constructor, I think that would fix this issue.
Depending on a record's field names / field selectors makes the generated code brittle. For example:
When the record you're using with
prairieshares field names with another record (e.g. you're usingderiveEsqueletoRecordwith the default settings), the code generated bymkRecordfails to compile because the record field accessors become ambiguous:That's with
-XDuplicateRecordFieldsenabled already.When you have
-XNoFieldSelectorsenabled, the field selectors are not in scope:If it's possible to use the fields by pattern matching / constructing them with positional arguments on the record's data constructor, I think that would fix this issue.