Hi, Am Dienstag, den 26.09.2017, 20:10 +0100 schrieb Simon Marlow:
It's a tradeoff and we could go either way, but I'll argue for being strict here. Suppose we have some code that uses the new extension and I compile it with GHC 8.2. The choice is between:
* without a new extension flag, GHC says "Parse error" * with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.
It's a choice between having metadata and a bit of extra work, vs. having no metadata and things sometimes failing.
it is also a choice between * extensions are testbeds and playgrounds for language extensions * extensions are what people build their products with I guess at some point, the former was true, and it was so successful that the second became true. I’d be sad if this leads to language extensions having to live up to the expectations to be perfect right from the start, and not be allowed to improve over a few releases. But I see the benefit of stability. Is it feasible to communicate their stability somehow? Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/