Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ban use of RecordWildCards in favor of OverloadedRecordDot #640

Open
martijnbastiaan opened this issue Sep 9, 2024 · 0 comments
Open

Ban use of RecordWildCards in favor of OverloadedRecordDot #640

martijnbastiaan opened this issue Sep 9, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@martijnbastiaan
Copy link
Contributor

martijnbastiaan commented Sep 9, 2024

We've collected quite a few cases where we follow a pattern like this:

foo SomeRecord{..} AnotherRecord{..} = 
  ( field1
  , field2
  )

While nice while writing the code (because the author is keenly aware of the fields in the various records), it makes it really hard to read the code. Specifically, it is difficult to trace the provenance of variables. Of course, in this very small example it's not that bad, but the problems are exacerbated when code becomes more spread out -- as it naturally tends to do.

With the introduction of OverloadedRecordDot (GHC 9.2) we can write the following instead:

foo someRecord anotherRecord = 
  ( someRecord.field1
  , anotherRecord.field2
  )

Note that we sometimes also do:

foo = SomeRecord{..}
 where
  field1 = ...
  field2 = ...

This is suffers from similar issues, though it doesn't have "great" solution except for just writing the names out with NamedFieldPuns:

foo = SomeRecord{field1, field2}
 where
  field1 = ...
  field2 = ...
@martijnbastiaan martijnbastiaan added the enhancement New feature or request label Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant