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 <bravit111@gmail.com> wrote:

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/proposals/0000-no-incomplete.rst

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