Add the method

[odersky]

the replaces infer, with the Shapeless semantics. This required
moving DottyPredef to src-bootstrapped since Scala 2.12 can't
express the semantics of the in a straightforward way.

Based on #5887

[propensive]

I think that the isn't a particularly good name for this. Being an article, it doesn't lend itself well to being used as a verb or noun, it sounds quite clunky when talked about verbally ("the the keyword") and unless it's marked up as code, is easily lost when reading a sentence. It has the advantage of being short, though.

I proposed, a while ago, that it might be possible to completely elide implicitly (and thus the) and to write the bare type in square brackets without any prefix at all, for example,

override def toString() = [Show[T]].show(myT)

At the time, Jason Zaugg reported that he had tried it and it caused problems with newline inference: I believe that a new line starting with [Type] would not cause a newline to be inferred, and it would be treated as a type application to whatever was at the end of the previous line. That, he considered, would break too much code if newline inference were to be changed.

Could this be reconsidered for Scala 3, though? I would particularly like the implied endorsement that witness resolution is such an important feature of Scala that it gets the most privileged syntax we can give it.

But I don't know the extent of the likely code breakage...

[jducoeur]

I think that the isn't a particularly good name for this.

I dunno. My initial reaction was "WTF?", but it does make a certain amount of sense. If implicit values are being repositioned as being "the definitive value for a type", then the is pretty logical. It focuses on the semantic meaning instead of the mechanism, which I like in principle. And I have to say, something like:

val ec = the[ExecutionContext]

reads rather well, IMO -- it's sensible English.

I agree that speaking about it is likely to be somewhat awkward, but I don't think that's a killer problem. On first blush, I'm mildly in favor of this one...

[odersky]

Compared to bare brackets, the has the big advantage that it does not require us to add another feature to the language for something that can be expressed perfectly well in the libraries.

I think in code the reads well. To talk about it, we need another term, but the same is true for bare brackets.

[godenji]

Interesting, how about bikeshed a little further on the syntax and go with the following:

def f given B, C : String = {
  imply a for A = the[B] // i.e. imply instead of implied
  the[A].show
}

[godenji]

Actually, why not go all the way?

def f given B, C : String = {
  imply a for A = by[B]
  by[A].show
}

I think it reads better with by than the, and I'm not sure what is gained with passive implied over active imply. In the end we need some syntax -- imply + by is rather pleasing to this eye.

[megri]

Devil's advocate: I think it's sometimes dangerous to create a syntax too similar to written english. When dealing with something like implicits, which carries a lot of rules, a seemingly innocent syntax may be misleading. While implicit and implicitly isn't perfect by any means, they're fairly explicit in how they look and feel.

Especially short words like the or by, to me, looks magical, and I'm not sure "magical" is a good thing in this context. I need to find more time to "feel" this new syntax so I'm undecided, but I think it is a good thing to keep in mind.

[LPTK]

The main drawback of the is that it doesn't make sense when not used with an explicit type argument. For example, while it does makes sense to write the following:

foo(bar, implicitly)
val foo: T = implicitly

...that looks out of place with the:

foo(bar, the)
val foo: T = the

while it still works great with infer:

foo(bar, infer)
val foo: T = infer

[milessabin]

I'm fine with the change, but I think that @LPTK's comments about the readability of the vs. infer are to the point.

When I chose the for shapeless, it was the uniqueness of the inferred value that I was concerned with, more than the inference part. infer, OTOH, focusses on the inference but doesn't suggest uniqueness, at least not so clearly.

One point in favour of the is that I would expect that existing uses of the (apart from in shapeless) in the ecosystem are far outnumbered by existing uses of infer, so adopting the would be much less disruptive.

[milessabin]

Other things to consider ...

• Idris uses the to express type ascriptions so there's a small possibility of confusion (FWIW I don't think the is a great choice for Idris here).
• the is impossible to google for. "shapeless the" gets you a couple of relevant hits, but I think "scala the" will always be hopeless.

[Jasper-M]

I proposed, a while ago, that it might be possible to completely elide implicitly (and thus the) and to write the bare type in square brackets without any prefix at all, for example,

override def toString() = [Show[T]].show(myT)

Ideally I would be able to keep writing Show[T].show(myT) (no brackets) without having to write the boilerplate

object Show {
  def apply[T](implicit show: Show[T]): show.type = show
}

Or without being screwed when the third party who wrote the typeclass forgot to write the extra boilerplate.

[odersky]

I agree that the works only with a type argument, but there it works well.

An alternative would be to have two methods. One would be the, the other a longer name that can work stand-alone. We could keep implicitly, or maybe use inferred instead.

Duplication like this is not nice, for sure. But I believe that the use case with type argument is common enough to warrant the optimal syntax for it.

[odersky]

Merging this now, since too much breaks for pending PRs at the moment.

[kjsingh]

the as a keyword - google and SO will need to improve their search algos :)