[ghc-steering-committee] #460: better migration for non-magical ~

Richard Eisenberg lists at richarde.dev
Fri Dec 17 22:38:58 UTC 2021


Hi all,

I am shepherding Proposal #460, an amendment to accepted proposal #371.

#371 proposed making the ~ operator completely non-magical in parsing, behaving syntactically like any other operator. It would have to be imported (though it would be exported from the Prelude, so most users get it for free), -XTypeOperators would have to be enabled, and its appearance is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but only very weakly: I gave a soft recommendation to accept, which Simon PJ trusted (but without much independent confirmation, it seems), Joachim gave a weak accept, and Alejandro and Arnaud said things mildly against (but did not quite vote for rejection).

Text for accepted proposal #371: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-non-magical-eq.md

This current #460 is a small amendment to #371 that makes the migration story gentler. All current programs would continue to be accepted for 8 releases. If ~ is used in a file without TypeOperators, a warning (enabled by default) triggers, saying that the user should enable TypeOperators. This fix is backward compatible. If ~ is used when it is out of scope (say, because a module does not import the Prelude), a warning (in -Wcompat) triggers. The fix is not backward compatible, because (~) is not currently exported from the Prelude. This warning gets moved from -Wcompat to the default warning set after 2 releases.

The previous migration story had no warning for a missing -XTypeOperators, meaning that some code would break immediately (although the fix is easy and backward compatible).

Text for amended proposal: https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals/0371-non-magical-eq.md
Amendment diff: https://github.com/ghc-proposals/ghc-proposals/pull/460/files

---

I recommend acceptance, because immediate breakage of code is bad: it causes kinks in the update cycle after a GHC release. This new migration story should be gentler, and poses little implementation burden.

Given the minor nature of this proposal, I will accept in one week if there is not dissent.

Thanks,
Richard


More information about the ghc-steering-committee mailing list