On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote: [...]
If we were to delay things, we would ship a version of the library that has missing functionality *and* we'll break everyone's code on the next release.
If we make the change now, then at least when people fix their TH code to work with GHC 8, they'd be getting access to more functionality.
This change does indeed change the data structure for declarations, so if you were working with it directly, indeed you'll have to make changes.
This so late in the process involves retroactively tighten upper bounds on template-haskell for existing releases on Hackage which already extended support to template-haskell-2.11. Sadly, I have lost track of how many packages were already updated several weeks ago since the first RC came out to work with template-haskell-2.11 so I don't have any numbers to offer nor a concrete list of which packages are likely candidates to become penalized for having been early adopters of GHC 8.0. So this will cause a regression on Hackage which will be actionable only after GHC 8.0 final gets out (unless we happen to have a RC4), as otherwise we'd break parts of Hackage for GHC 8.0 RC3 users (this includes Travis jobs already including GHC 8.0 in their configs) However, I do sympathize with the desire to get this in while it's still relatively cheap, rather than have to wait a year until it's time for template-haskell-2.12 ... Would you be willing to help out with making sure popular packages depending on template-haskell[1] are brought up speed as soon as your proposed change lands to reduce the pain/cost of such a last-minute change? [1]: http://packdeps.haskellers.com/reverse/template-haskell
However, if you use the "smart" constructors in TH, you shouldn't need to change anything. In particular, I left `instanceD` as before---it does not add any overlapping pragmas, and I added a new function `instanceWithOverlapD`, which has an extra parameter that allows you to specify pragmas.
I'd like to get this in, if possible, as I have a library that needs this feature. My current work-around it quite ugly: ask the clients of the library to enable "Language OverlappingInstaces", which is cumbersome, *and* generates deprecation warnings.