RFC: Remove -fwarn-unticked-promoted-constructors from -Wall

[Richard Eisenberg]

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 <jan.stolarek at p.lodz.pl> 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
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs