For what it's worth, I don't have a strong feeling either way here. Arguments in favor of keeping -fwarn-unticked-promoted-constructors in -Wall: 1. It's weird having GHC look in one namespace (types) and then look in another (terms) only when the first one fails. In other scenarios, ambiguity is an error.
2. If I have my way (https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell), this problem will only get worse. 3. Whenever presenting code involving promoted constructors, I put the tick marks in everywhere, as I think it makes the code easier to understand. 4. There is an easy workaround: > type Unbranched = 'Unbranched Arguments against keeping -fwarn-unticked-promoted-constructors in -Wall: 1,2. As Janek. 3. If you've made a mistake around using a type where a promoted data constructor is meant, or vice versa, it's very likely you have an error in your code. This will lead to a perhaps-obscure, perhaps-confusing error message instead of a nice clean warning, which is suppressed when there are errors. Adding this all up, I can't really decide which is best. Richard On Dec 18, 2014, at 12:26 PM, Jan Stolarek <[email protected]> wrote: > We recently got a new warning -fwarn-unticked-promoted-constructors (see > #9778 and D534). This > warning is enabled with -Wall but I think that this is not a good idea. I > strongly propose to > remove it with -Wall. > > Rationale: > 1. I feel that ticks add unnecessary noise: > > prDictOfPReprInstTyCon :: Type -> CoAxiom 'Unbranched -> [Type] -> VM CoreExpr > > To me it feels awkward to have Unbranched with a tick but CoreExpr without a > tick (both are types > after all). Moreover, ticks also trip many syntax highlighters, which further > degrades code > readability. > > 2. I've been refactoring some of GHC code to use promoted types instead of > empty data types (see > CoAxiom.BranchList). This would have been a fairly local change, except that > I have to add ticks > in every place that mentiones promoted types. That's a Royal Pain and a > "good" example how this > warning can get in people's way. > > Janek > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
