I would support this, but only if
1. we specify precisely exactly which pattern matches are accepted, and
2. GHC accepts only those patterns when NoIncomplete is enabled
That is, it would certainly be a subset of -Wincomplete-patterns. No
cleverness, no adding extra magic to accept more programs with each
release. The point of a spec is to say exactly which programs are accepted,
in such a way that different implementations can implement the feature
consistently - one implementation is not allowed to accept more programs,
otherwise there's no point in having a definition of the feature.
If we don't want to do this (and I suspect it would be annoying to
implement), then I think -Werror is the best alternative.
Cheers
Simon
On Wed, 26 May 2021 at 13:33, Vitaly Bragilevsky
Dear Committee,
We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance.
The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351 The rendered version: https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/...
The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag.
I think this feature comes quite handy in education. I'd use it all the time with my students.
Please comment here or in the GitHub thread if you see any problems with this proposal.
Vitaly
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee