Warn users on non canonical type references

[nicolasstucki]

Help users write the correct variant of the quoted type encoding.
Explicit construction of a scala.quoted.Type[_] should be done with its constructor.
Explicit construction of types in not encouraged as it should be created implicitly.
Creating an Type explicitly is only useful for debugging purposes.
Likewise, we encourage the use of the explicit inner type reference.

[liufengyun]

It seems '[T] is more symmetric here.

[nicolasstucki]

Indeed, and that is why it should not be used. The syntactic symmetry is what lead to most conceptual misunderstandings of how Type works.

This constructor should also never be used explicitly and giving it a shorter alias does not help users avoid the explicit use.

It is also uncertain that the case '[...] pattern will be kept. We might remove them and use only a single matching abstraction as we do with inline match.

[liufengyun]

If the usage is bad, what about disallowing it in syntax?

[nicolasstucki]

That is my intent as I explain in #9486. This is a first step to help migration. We can drop the syntax later on once users have adapted. I would prefer to have at least one release with a warning.

[liufengyun]

Might be good to bring this up in the meeting, as it's syntax related.

[nicolasstucki]

This specific case is a corner case that should be avoided. It should have been written explicitly as

def summonTypedType[T : Type](using QuoteContext): String = summon[Type[T]] match { ...
// or 
def summonTypedType[T](using tp: Type[T])(using QuoteContext): String = tp match { ...

[liufengyun]

Can we rewrite this test to remove the '[Byte] syntax?

[liufengyun]

LGTM

[liufengyun]

Can we rewrite this test to remove the '[Byte] syntax?

[nicolasstucki]

Can we rewrite this test to remove the '[Byte] syntax?

I added tests/patmat/i9489b.scala which uses '{...} to do the same.

[liufengyun]

Can we rewrite this test to remove the '[Byte] syntax?

I added tests/patmat/i9489b.scala which uses '{...} to do the same.

The alternative approach does not look as nice as the previous version. Will it be simpler to do it using reflect API? Or, users should use if/else instead of match? I think if/else is acceptable if it works.

[nicolasstucki]

We could add =:= to support if/else for that precise use case. But the pattern match case '[...] will still be needed as it is more expressive. I'm not sure why you wanted to try without the case '[...] in the first place.

[liufengyun]

I'm not sure why you wanted to try without the case '[...] in the first place.

Just for consistency, if we remove the '[T] syntax, we would not want users to use them as patterns.

[nicolasstucki]

Not sure is we will remove '[..] for patterns. The asymmetric nature of quoted types demands some asymmetry in the API. We might rework the syntax later if we see the need.

This PR in combination with #10045 aims to make users of t: Type[X] use X directly everywhere and never a t.T. Unless they really want to.