Conversions, into & Implicit Resolution

into[T] is an opaque type, defined in the companion of Conversion, that marks a type as a conversion target. Where the expected type is into[T], a conversion to T is inserted with no import and no warning:

Source: Scala 3 Reference: The into Type and Modifier

The call to total converts only the Int arguments, one by one, because into applied to a vararg parameter converts each argument on its own. The call to plain is outside any into and gets the feature warning. The same program compiles and runs the same on 3.9.0.

into also works in other positions that the compiler treats as expected types: parameters of enum cases (so that a tree type accepts Add(1, Neg(2)) where 1 is an Int converted to a Const), and the result of a function argument. The second example shows both, plus what happens inside the method body: the compiler erases into from the types of parameters as seen in the body, so a.km needs no unwrapping. Outside a body, .underlying of Conversion takes the wrapper off:

Source: Scala 3 Reference: The into Type and Modifier, into as a type constructor

An enum shows the intended use for a tree or a small DSL: only the constructor parameters convert.

A type parameter instantiated to an into type also counts (List[into[Keyword]]("if", "then", "else") converts the strings), but the conversion target is only recognised where the type is fully known. The reference warns that a value declared as List[into[Keyword]] and built from List(ifKW, "then", "else") does not get the permission, and in 3.10 that is reported as the ordinary feature warning for the two strings, not as an error (checked with -feature).

Source: Scala 3 Reference: The into Type and Modifier

If you own the target type, mark it instead of changing every signature. into is a soft modifier on classes, traits and opaque type aliases, and conversions into the type then need no import wherever it is the expected type:

This form is meant for a small set of designated conversion targets, such as a framework type used as a parameter type everywhere. The reference states the limit plainly: keep the number of into types to the absolute minimum, and never make a type into just in case someone might want to add a conversion later.

A valid conversion target type, the one that allows conversions without the import, is one of these: into[T]; a class, trait or opaque type declared into, with any type arguments; a type alias, match type, annotated type or refined type whose underlying type is valid; a union or intersection of two valid types; or a type parameter explicitly instantiated to a valid type. The reference motivates the feature with the list concatenation xs ys` where `ys` is an array: the parameter of ` would be declared as into[IterableOnce[A]] so that the array converts without an import at the call site.

Source: Scala 3 Reference: The into Type and Modifier, conversion target types

Source: Scala 3.9 release notes

A definition nested more deeply wins over an outer one, so the nearest given is picked instead of reporting an ambiguity. Scala 2 reports the ambiguity. The same program, one version in each language:

The same shape in Scala 2.13.18, with implicit parameters, fails:

Source: Scala 3 Reference: Changes in Implicit Resolution, nesting

A package prefix no longer contributes to the implicit scope of a type. A given defined at package level next to a type is not in the implicit scope of that type from other packages, whereas a given in an object that the type lives in is. The two files below define a type in an object o inside package p, with one given in o and one at the package level, and use it from package q:

Source: Scala 3 Reference: Changes in Implicit Resolution

Source: Scala 3 Reference: Changes in Implicit Resolution

Only the given in o is found. Put instances in the companion or in an object on the path of the type, or import them.

If an ambiguity is found while the compiler is resolving the arguments of a given, it is reported to the caller instead of silently discarding that candidate (Scala 2 treated it as a plain failure of the candidate and went on, which people used to simulate negation; use scala.util.NotGiven for that now). Here b needs an A, and there are two:

Source: Scala 3 Reference: Changes in Implicit Resolution

Adding a plain given Show[B] next to it makes the program compile and print plain: it is then the only candidate that does not depend on the ambiguous A. Divergence is also treated differently: a divergent candidate is a normal failure after which other candidates are still tried.

When several givens match, Scala 3.0 to 3.6 picked the one with the most specific type. Scala 3.7 picks the most general one that satisfies the request. The reference sums it up with this example, in which the old rules reported an ambiguity:

The same file gives different answers by release (checked): 3.9.0 and 3.10.0 print A and B. With Scala 3.3.8 and with -source:3.5 the first summon is rejected with "Ambiguous given instances: both given instance given_B …​ and given instance given_C …​ match type trailhead.A". Compiling with -source:3.7-migration keeps the new behaviour and prints a warning at each place where the choice changed ("Given search preference for trailhead.A between alternatives …​ has changed. Previous choice: the first alternative. Choice from Scala 3.7: the second alternative.").

The consequence for library design: a given for a general type now shadows more specific instances that sit at the same level, so a base-type fallback no longer makes the specific instances ambiguous. Other rules that changed in 3.0: a given that takes using parameters is less specific than one that takes none, all else being equal; the old Scala 2 preference for conversions with call-by-value over call-by-name parameters is gone; and the type of an implicit val or implicit def has to be written explicitly (except in local blocks).

Source: Scala 3.7.0 release notes

Implicit search used to look into the companion of a type even when the call site could not refer to that companion, so a private companion could still contribute givens. The specification has always required an eligible given to be accessible at the point of the call. Scala 3.9 reports the use as a deprecation warning, and Scala 3.10 stops finding such instances:

With 3.9.0 and -deprecation the same file compiles and prints hidden default, and the compiler says: "Usage of implicit given instance given_Config defined in object Config, which is not accessible here. In Scala 3.10, this implicit will no longer be found." Without -deprecation 3.9.0 reports only "there was 1 deprecation warning". With 3.3.8 the file compiles and prints hidden default. The fix, for a library, is to make the companion public or to move the given to a public object. The release notes say that about 20 projects in the community build stopped compiling on 3.10 for this reason, and that a user often cannot fix it in their own code because the instance lives in a library.

Source: Scala 3.10 release notes

Scala 3 writes explicit arguments for a context parameter with using, so that it is never confused with an argument to the apply of the result. For a Scala 2 style implicit parameter, omitting using is allowed but, since 3.7, warns:

For a real using clause the plain form is an error: withUsing(Config("explicit")) does not mean "pass this argument" but "no given for parameter c", and the compiler reports "No given instance of type Config was found for parameter c of method withUsing". Run with 3.3.8 the first line compiles without a warning. The rewrite -rewrite -source 3.7-migration inserts the using keyword for you.

Source: Scala 3.7.0 release notes