Suggest -XScopedTypeVariables instead of -XRankNTypes

When the parser encounters an explicit forall when -XExplicitForAll is disabled, it tries to guess what the user meant and suggests to enable -XRankNTypes:

    Perhaps you intended to use RankNTypes or a similar language
    extension to enable explicit-forall syntax: forall <tvs>. <type>

Richard argues we are better off suggesting -XScopedTypeVariables by default:

Consider these workflows:

1a. User is writing a higher-rank type without extensions. GHC suggests to enable RankNTypes. Program is accepted.

1b. User is writing a higher-rank type without extensions. GHC suggests to enable ScopedTypeVariables. User compiles again, and GHC suggests to enable RankNTypes. Program is accepted.

2a. User is writing a program that requires scoped type variables. GHC suggests to enable RankNTypes. Program is rejected with inscrutable type errors claiming that a is not a0.

2b. User is writing a program that requires scoped type variables. GHC suggests to enable ScopedTypeVariables. Program is accepted.

The question is: what's worse: 1b, or 2a? I claim that 2a is worse, and so I favor making the change so that we avoid 2a in favor of sometimes incurring 1b.

The problem here is that in the grand scheme of things, we want neither 1b nor 2a to happen. What would it take to implement a proper diagnostic and always suggest the appropriate extension?

Trac metadata

Trac field	Value
Version	8.6.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (Parser)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	goldfire
Operating system
Architecture

changed weight to 5

added Tfeature request Trac import parser labels

added Pnormal label

This was also reported at #18468 (closed). I'll close this ticket, as the other one has a recent discussion.

closed

mentioned in issue #18468 (closed)