Implement into modifier on parameter types

[odersky]

in the thread https://contributors.scala-lang.org/t/proposed-changes-and-restrictions-for-implicit-conversions/4923
we discussed two changes that would make implicit conversions largely redundant. One proposed change was implemented in #14497. The other is implemented here. It's based on #14497.

The idea of this PR is to have some way to specify that a method parameter accepts implicit conversions on its arguments. Then the feature warning on implicit conversion use would be suppressed in this case. In the previous thread I proposed
~ to mark convertible arguments but I now feel this is too cryptic. Instead there is a into prefix in the
parameter type. E.g.

  def f(x: into T) = ...

For Scala 2, we introduce an annotation on the parameter that expresses the same thing:

  // proposed Scala-2 syntax:
  def f(@allowConversions x: T) = 

A larger example:

given Conversion[String, Text] = Text(_)

@main def Test =

  def f(x: into Text, y: => into Text, zs: into Text*) =
    println(s"${x.str} ${y.str} ${zs.map(_.str).mkString(" ")}")

  f("abc", "def")  // ok, no feature warning
  f("abc", "def", "xyz", "uvw")  // also ok
  f("abc", "def", "xyz", Text("uvw"))  // also ok

A larger example is a parser combinator library that works without unrestricted implicit conversions:
tests/run/Parser.scala

[odersky]

Open questions

1. Is this the right way to express implicit convertibility in source?
2. Internally we mark convertible parameters with the annotation @scala.annotation.internal.$convertible. Is this the right way to do it, or do we prefer a more robust scheme?

[odersky]

The last commit bases the implementation on an internal alias type instead of an annotation. This makes
convertibleTo handling unforgeable.

[nicolasstucki]

Will we need to extend this concept at some point to lambdas?

[odersky]

I went ahead and made this an experimental feature so that people can try it out.

Points to note:

• When Scala 3 conversions are applied implicitly they currently require an implicitConversions language import at the use site. (Old style Scala 2 implicit conversions required the language import at definition site, but that turned out to be toothless).
• With this PR there is now an exception: No language import is required if the implicit conversion is on a method argument where the corresponding parameter is marked into.

This technique addresses the situations where implicit conversions were found to be essential and hard to replace in the discussion thread cited above.

[deusaquilus]

@odersky I'm so sorry to keep pestering you about this but after you closed #16002 I really don't know what else to do. For Quill to work I need to have both implicit conversions Quoted[T] => T and T => Quoted[T]. The into capability might help with the T => Quoted[T] part but it's the Quoted[T] => T that is much more important (I mentioned that on the original thread here).

At this point, the only thing that can save Quill from an eternity of needing implicit-conversions is some kind of injectable Quoted[T] => T conversion that would be injected into quote { ... } blocks. Without something like that, every other kind of feature like this one is completely pointless for Quill.

[odersky]

@deusaquilus I don't know a solution either. Maybe Quill won't profit from into. I am not sure what else can be done. For the moment, the language import might be the only way to do it.

[odersky]

@dwijnand Can you give this a review?

[odersky]

The reason to merge this now is that I'd like to experiment with the compiler to see whether we can get rid of implicit conversions. We need to make progress on this since old style implicit conversions will be deprecated at some point and new style implicit conversions require a language import at the use site.

To make this work, we need to have alternative mechanisms in place that make implicit conversions necessary only in exceptional cases. into is such a mechanism, and right now it is not clear whether it is already sufficient or we need something else as well. Now, the compiler contains thousands of occurrences of implicit conversions. So it is an ideal testing ground to see how far we get in getting rid of them. And before we start we need into.

[KacperFKorban]

LGTM overall. Just added some minor comments.

Also sorry for causing this PR to hang for so long, I must've dismissed the notification by accident.

[odersky]

@KacperFKorban Thanks for the review!