<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Dear all,<div><br></div><div>As some of you might know, for the past few months I have been working on changing GHC's diagnostic messages from plain SDocs to richer Haskell types.</div><div><br></div><div>As part of this work, I have added a mechanism to embed hints into diagnostics, defined in `GHC.Types.Hint` in `HEAD`. One of the main workhorse of this `GhcHint` type is the `SuggestExtension LangExt.Extension` constructor, which embeds the extension to enable to use a particular feature. The `LangExt.Extension` type comes from `GHC.LanguageExtensions.Types`, and up until now there has always been a 1:1 mapping between the language pragma for the extension and the type itself.</div><div><br></div><div>Today I was working on turning this error into a proper Haskell type:</div><div><br></div><div><div>badPun :: Located RdrName -> TcRnMessage</div><div>badPun fld = TcRnUnknownMessage $ mkPlainError noHints $</div><div>  vcat [text "Illegal use of punning for field" <+> quotes (ppr fld),</div><div>        text "Use NamedFieldPuns to permit this"]</div></div><div><br></div><div>I was ready to yield a `SuggestExtension LangExt.NamedFieldPuns` when I discovered that there is no `NamedFieldPuns` constructor. Rather, there is a `RecordPuns` , which refer to a deprecated flag, and we simply map `NamedFieldPuns` back to it in `GHC.Driver.Session`:</div><div><br></div><div>...</div><div><div>  depFlagSpec' "RecordPuns"                   LangExt.RecordPuns</div><div>    (deprecatedForExtension "NamedFieldPuns"),</div></div><div>...</div><div><div>  flagSpec "NamedFieldPuns"                   LangExt.RecordPuns,</div></div><div>...</div><div><br></div><div>This is problematic for the `GhcHint` type, because now if I was to yield `SuggestExtension LangExt.RecordPuns` to the user, I could still pretty-print the suggestion to turn `RecordPuns` into `NamedFieldPuns`, but this means that IDEs or third-party library would have access to the </div><div>"raw" Haskell datatype, and at that point they will be stuck with a suggestion to enable a deprecated extension! (or best case scenario they will have to transform the suggestion into something more sensible, which partially defeats the point of this refactoring work I have been doing).</div><div><br></div><div>I am not sure this behaviour is unique for just `NamedFieldPuns`, but my question is:</div><div><br></div><div>1. What prevents us from adding `NamedFieldPuns` as a proper constructor for the `Extension` type and in principle remove `RecordPuns`? Backward compatibility I assume?</div><div><br></div><div> </div><div>Many thanks,</div><div><br></div><div>Alfredo</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div>