Make -explain-types a -Y option as -Yexplain-types.

[sjrd]

It prints compiler implementation details about constraint solving.

[sjrd]

Sigh ... Apparently discipline-munit uses that flag in their build ...

[odersky]

I am actually not sure about that one. explainTypes gives generally applicable info why a type does not conform to another. It's useful, and we will want to keep it always accessible. So hiding it behind -Y seems to restrive. I would opt for a -X flag, or else leave it as it is.

[griggt]

I believe the usage of -explain-types in projects in the community build is via the sbt-tpolecat plugin.

https://github.com/DavidGregory084/sbt-tpolecat/blob/270b2238b97e9b5a647918753e5b6405075532c4/src/main/scala/io/github/davidgregory084/TpolecatPlugin.scala#L51

[SethTisue]

Should be a -V flag, IMO.

related: scala/scala#7785

[smarter]

If we want it to be user-visible we need to change what it does: right now it prints the constraint set in a format which might be completely unrelated to the current subtyping check and so be confusing (especially since it's not printed in a way that is meant to be understandable for users).

[som-snytt]

It's worth noting that in Scala 2's -V -W -X -Y scheme, there is no policy whether -V -W are "stable". They are informational only, so it's benign if -Vfoo is a no-op (but not removed, to give sbt-tpolecat a break). By contrast, -X -Y are behavioral. I find -V aids discoverability. I'm agnostic whether -V means "user-visible, so all verbose output has to be user-accessible." By agnostic I mean apostate. I actually think a user might want "more and more output" analogous to logging levels, INFO or DEBUG, which may be cryptic.

[SethTisue]

Fully agree with Som here. We regard it as normal (within reason) in Scala 2 to change -V and -W around in minor releases.