NamedFieldPuns should allow "ambiguous" field names
Consider the following example:
{-# LANGUAGE NamedFieldPuns #-}
import DupType
data A = A { field :: Int }
f :: A -> Int
f A { field } = field
with
module DupType where
data B = B { field :: Int }
This results in the following error:
A.hs:8:7: error:
Ambiguous occurrence ‘field’
It could refer to either ‘DupType.field’,
imported from ‘DupType’ at A.hs:3:1-14
(and originally defined at DupType.hs:3:14-18)
or ‘Main.field’, defined at A.hs:5:14
|
8 | f A { field } = field
| ^^^^^
This seems like poor behavior, because since a particular constructor is used, it is unambiguous which field is intended. In particular, this is inconsistent with RecordWildCards
. Consider that f A { .. } = field
compiles perfectly fine.
I actually encountered this issue in a bit of a different usecase. I was using NamedFieldPuns
along with DuplicateFieldNames
. However, I got the constructor name wrong. After the scope error in the output, there was an ambiguous field name error. This was quite confusing because DuplicateFieldNames
was on, so ambiguity should be fine! Took me a while to realize that the scope error was the root issue. With the constructor name fixed, the code compiled. If the constructor was used to resolve field names, then the 2nd error wouldn't have been emitted.
I realize that broadening the code allowed by NamedFieldPuns
could lead to issues where code written for newer GHC versions does not work with older GHC versions. This certainly will not change the meaning of older code. What's the policy on this?