Skip to content

Commit 9eb60f1

Browse files
committed
Refine import implied rules to smooth migration
1 parent 757e2d1 commit 9eb60f1

File tree

1 file changed

+22
-0
lines changed

1 file changed

+22
-0
lines changed

docs/docs/reference/contextual/import-implied.md

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,3 +27,25 @@ There are two main benefits arising from these rules:
2727
without importing anything else. This is particularly important since implied
2828
instances can be anonymous, so the usual recourse of using named imports is not
2929
practical.
30+
31+
### Relationship with Old-Style Implicits
32+
33+
The rules of implied imports above have the consequence that a library
34+
would have to migrate in lockstep with all its users from old style implicits and
35+
normal imports to implied instances and imports.
36+
37+
The following modifications avoid this hurdle to migration.
38+
39+
1. An implied import also brings old style implicits into scope. So, in Scala 3.0
40+
an old-style implicit definition can be brought into scope either by a normal or
41+
by an implied import.
42+
43+
2. In Scala 3.1, an old-style implicits accessed implicitly through a normal import
44+
will give a deprecation warning.
45+
46+
3. In some version after 3.1, an old-style implicits accessed implicitly through a normal import
47+
will give a compiler error.
48+
49+
Thr rules mean that library users can use `import implied` to access old-style implicits in Scala 3.0,
50+
and will be gently nudged and then forced to do so in later versions. Libraries can then switch to
51+
implied instances once their user base has migrated.

0 commit comments

Comments
 (0)