Open michaelpj opened 2 years ago
cc @July541
They are different I think, your issue seems easy to deal.
I’m on vocation and will check it several days later:)
From my test, the constraints can be omitted if our implementation doesn't rely on them like f
below, while constraints are required if we use them like g
below.
Currently, hls-class-plugin displays constraints no matter we use them because it doesn't know whether we'll use them later while creating the signature.
Or, should we dynamically change the signature lens depending on users' implementation?
Is it possible to rely on hlint to give a hint for redundant constraints for instance methods?
On 1.8.0
The lenses for the class plugin show type signatures that include any context from the class itself, e.g.
(those constraints appear on the class). This is unnecessary: you can delete the constraints and the signature works because they're implied.
This is I think a similar problem to what we had here https://github.com/haskell/haskell-language-server/pull/2966#discussion_r901413885
I'm not totally sure what to do. Maybe we can ask the GHC devs if there's a way to get the right answer here. Maybe we can just remember the constraints that are in scope and try and get rid of them?