Erased Terms
Why erased terms? The following examples shows an implementation of a simple state machine which can be in a state On or Off. The machine can change state from Off to On with turnedOn only if it is currently Off. This last constraint is captured with the IsOff[S] implicit evidence which only exists for IsOff[Off]. For example, not allowing calling turnedOn on in an On state as we would require an
Implicit By-Name Parameters
Call-by-name implicit parameters can be used to avoid a divergent implicit expansion. trait Codec[T] { def write(x: T): Unit } implicit def intCodec: Codec[Int] = ??? implicit def optionCodec[T] (implicit ev: => Codec[T]): Codec[Option[T]] = new { def write(xo: Option[T]) = xo match { case Some(x) => ev.write(x) case None => } } val s = implicitly[Codec[Option[Int]]] s.write(Some(33)) s.write(None
Changes in Implicit Resolution
Implicit resolution uses a new algorithm which caches implicit results more aggressively for performance. There are also some changes that affect implicits on the language level. Types of implicit values and result types of implicit methods must be explicitly declared. Excepted are only values in local blocks where the type may still be inferred: class C { val ctx: Context = ... // ok /*!*/ implic
Implicit Conversions
An implicit conversion, also called view, is a conversion that is applied by the compiler in several situations: When an expression e of type T is encountered, but the compiler needs an expression of type S. When an expression e.m where e has type T but T defines no member m is encountered. In those cases, the compiler looks in the implicit scope for a conversion that can convert an expression of
Option-less pattern matching
Dotty implementation of pattern matching was greatly simplified compared to scalac. From a user perspective, this means that Dotty generated patterns are a lot easier to debug, as variables all show up in debug modes and positions are correctly preserved. Dotty supports a superset of scalac's extractors. Boolean Pattern Extractor defines def unapply(x: T): Boolean Pattern-matching on exactly 0 pat
Automatic Eta Expansion
Previously, a method reference m was converted to a function value only if the expected type was a function type. If that was not the case, one had to write m _ to force the conversion (which is called eta-expansion). For methods with one or more parameters, this restriction has now been dropped. Example: def m(x: Boolean, y: String)(z: Int): List[Int] val f1 = m val f2 = m(true, "abc") This creat
Auto-Application
Previously an empty argument list () was implicitly inserted when calling a nullary method without arguments. E.g. def next(): T = ... next // is expanded to next() In Dotty, this idiom is an error. next ^ missing arguments for method next In Dotty, the application syntax has to follow exactly the parameter syntax. Excluded from this rule are methods that are defined in Java or that override metho
Dependent Function Types
A dependent function type describes functions where the result type may depend on the function's parameter values. Example: trait Entry { type Key; val key: Key } def extractKey(e: Entry): e.Key = e.key // a dependent method val extractor: (e: Entry) => e.Key = extractKey // a dependent function value // ║ ⇓ ⇓ ⇓ ⇓ ⇓ ⇓ ⇓ ║ // ║ Dependent ║ // ║ Function Type ║ // ╚═══════════════════╝ Scala already
Higher-Kinded Types in Dotty
Higher-Kinded Types in Dotty V2 This note outlines how we intend to represent higher-kinded types in Dotty. The principal idea is to collapse the four previously disparate features of refinements, type parameters, existentials and higher-kinded types into just one: refinements of type members. All other features will be encoded using these refinements. The complexity of type systems tends to grow
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDE support for Scala 3
Scala 3