|
| 1 | +/* __ *\ |
| 2 | +** ________ ___ / / ___ Scala API ** |
| 3 | +** / __/ __// _ | / / / _ | (c) 2003-2015, LAMP/EPFL ** |
| 4 | +** __\ \/ /__/ __ |/ /__/ __ | http://scala-lang.org/ ** |
| 5 | +** /____/\___/_/ |_/____/_/ | | ** |
| 6 | +** |/ ** |
| 7 | +\* */ |
| 8 | +package scalaShadowing |
| 9 | + |
| 10 | +/** |
| 11 | + * The `scala.language` object controls the language features available to the programmer, as proposed in the |
| 12 | + * [[https://docs.google.com/document/d/1nlkvpoIRkx7at1qJEZafJwthZ3GeIklTFhqmXMvTX9Q/edit '''SIP-18 document''']]. |
| 13 | + * |
| 14 | + * Each of these features has to be explicitly imported into the current scope to become available: |
| 15 | + * {{{ |
| 16 | + * import language.postfixOps // or language._ |
| 17 | + * List(1, 2, 3) reverse |
| 18 | + * }}} |
| 19 | + * |
| 20 | + * The language features are: |
| 21 | + * - [[dynamics `dynamics`]] enables defining calls rewriting using the [[scala.Dynamic `Dynamic`]] trait |
| 22 | + * - [[postfixOps `postfixOps`]] enables postfix operators |
| 23 | + * - [[reflectiveCalls `reflectiveCalls`]] enables using structural types |
| 24 | + * - [[implicitConversions `implicitConversions`]] enables defining implicit methods and members |
| 25 | + * - [[higherKinds `higherKinds`]] enables writing higher-kinded types |
| 26 | + * - [[existentials `existentials`]] enables writing existential types |
| 27 | + * - [[experimental `experimental`]] contains newer features that have not yet been tested in production |
| 28 | + * |
| 29 | + * and, for dotty: |
| 30 | + * |
| 31 | + * - [[Scala2 `Scala2`] backwards compatibility mode for Scala2 |
| 32 | + * - [[noAtoTupling `noAutoTupling`]] disable auto-tupling |
| 33 | + * |
| 34 | + * @groupname production Language Features |
| 35 | + * @groupname experimental Experimental Language Features |
| 36 | + * @groupprio experimental 10 |
| 37 | + * |
| 38 | + * Dotty-specific features come at the end. |
| 39 | + * |
| 40 | + * Note: Due to the more restricted language import mechanism in dotty (only |
| 41 | + * imports count, implicits are disregarded) we don't need the constructions |
| 42 | + * of the inherited language features. A simple object for each feature is |
| 43 | + * sufficient. |
| 44 | + */ |
| 45 | +object language { |
| 46 | + |
| 47 | + import languageFeature._ |
| 48 | + |
| 49 | + /** Where enabled, direct or indirect subclasses of trait scala.Dynamic can |
| 50 | + * be defined. Unless dynamics is enabled, a definition of a class, trait, |
| 51 | + * or object that has Dynamic as a base trait is rejected. Dynamic member |
| 52 | + * selection of existing subclasses of trait Dynamic are unaffected; |
| 53 | + * they can be used anywhere. |
| 54 | + * |
| 55 | + * '''Why introduce the feature?''' To enable flexible DSLs and convenient interfacing |
| 56 | + * with dynamic languages. |
| 57 | + * |
| 58 | + * '''Why control it?''' Dynamic member selection can undermine static checkability |
| 59 | + * of programs. Furthermore, dynamic member selection often relies on reflection, |
| 60 | + * which is not available on all platforms. |
| 61 | + * |
| 62 | + * @group production |
| 63 | + */ |
| 64 | + @volatile implicit lazy val dynamics: dynamics = languageFeature.dynamics |
| 65 | + |
| 66 | + /** Only where enabled, postfix operator notation `(expr op)` will be allowed. |
| 67 | + * |
| 68 | + * '''Why keep the feature?''' Several DSLs written in Scala need the notation. |
| 69 | + * |
| 70 | + * '''Why control it?''' Postfix operators interact poorly with semicolon inference. |
| 71 | + * Most programmers avoid them for this reason. |
| 72 | + * |
| 73 | + * @group production |
| 74 | + */ |
| 75 | + @volatile implicit lazy val postfixOps: postfixOps = languageFeature.postfixOps |
| 76 | + |
| 77 | + /** Only where enabled, accesses to members of structural types that need |
| 78 | + * reflection are supported. Reminder: A structural type is a type of the form |
| 79 | + * `Parents { Decls }` where `Decls` contains declarations of new members that do |
| 80 | + * not override any member in `Parents`. To access one of these members, a |
| 81 | + * reflective call is needed. |
| 82 | + * |
| 83 | + * '''Why keep the feature?''' Structural types provide great flexibility because |
| 84 | + * they avoid the need to define inheritance hierarchies a priori. Besides, |
| 85 | + * their definition falls out quite naturally from Scala’s concept of type refinement. |
| 86 | + * |
| 87 | + * '''Why control it?''' Reflection is not available on all platforms. Popular tools |
| 88 | + * such as ProGuard have problems dealing with it. Even where reflection is available, |
| 89 | + * reflective dispatch can lead to surprising performance degradations. |
| 90 | + * |
| 91 | + * @group production |
| 92 | + */ |
| 93 | + @volatile implicit lazy val reflectiveCalls: reflectiveCalls = languageFeature.reflectiveCalls |
| 94 | + |
| 95 | + /** Only where enabled, definitions of implicit conversions are allowed. An |
| 96 | + * implicit conversion is an implicit value of unary function type `A => B`, |
| 97 | + * or an implicit method that has in its first parameter section a single, |
| 98 | + * non-implicit parameter. Examples: |
| 99 | + * |
| 100 | + * {{{ |
| 101 | + * implicit def stringToInt(s: String): Int = s.length |
| 102 | + * implicit val conv = (s: String) => s.length |
| 103 | + * implicit def listToX(xs: List[T])(implicit f: T => X): X = ... |
| 104 | + * }}} |
| 105 | + * |
| 106 | + * implicit values of other types are not affected, and neither are implicit |
| 107 | + * classes. |
| 108 | + * |
| 109 | + * '''Why keep the feature?''' Implicit conversions are central to many aspects |
| 110 | + * of Scala’s core libraries. |
| 111 | + * |
| 112 | + * '''Why control it?''' Implicit conversions are known to cause many pitfalls |
| 113 | + * if over-used. And there is a tendency to over-use them because they look |
| 114 | + * very powerful and their effects seem to be easy to understand. Also, in |
| 115 | + * most situations using implicit parameters leads to a better design than |
| 116 | + * implicit conversions. |
| 117 | + * |
| 118 | + * @group production |
| 119 | + */ |
| 120 | + @volatile implicit lazy val implicitConversions: implicitConversions = languageFeature.implicitConversions |
| 121 | + |
| 122 | + /** Only where this flag is enabled, higher-kinded types can be written. |
| 123 | + * |
| 124 | + * '''Why keep the feature?''' Higher-kinded types enable the definition of very general |
| 125 | + * abstractions such as functor, monad, or arrow. A significant set of advanced |
| 126 | + * libraries relies on them. Higher-kinded types are also at the core of the |
| 127 | + * scala-virtualized effort to produce high-performance parallel DSLs through staging. |
| 128 | + * |
| 129 | + * '''Why control it?''' Higher kinded types in Scala lead to a Turing-complete |
| 130 | + * type system, where compiler termination is no longer guaranteed. They tend |
| 131 | + * to be useful mostly for type-level computation and for highly generic design |
| 132 | + * patterns. The level of abstraction implied by these design patterns is often |
| 133 | + * a barrier to understanding for newcomers to a Scala codebase. Some syntactic |
| 134 | + * aspects of higher-kinded types are hard to understand for the uninitiated and |
| 135 | + * type inference is less effective for them than for normal types. Because we are |
| 136 | + * not completely happy with them yet, it is possible that some aspects of |
| 137 | + * higher-kinded types will change in future versions of Scala. So an explicit |
| 138 | + * enabling also serves as a warning that code involving higher-kinded types |
| 139 | + * might have to be slightly revised in the future. |
| 140 | + * |
| 141 | + * @group production |
| 142 | + */ |
| 143 | + @volatile implicit lazy val higherKinds: higherKinds = languageFeature.higherKinds |
| 144 | + |
| 145 | + /** Only where enabled, existential types that cannot be expressed as wildcard |
| 146 | + * types can be written and are allowed in inferred types of values or return |
| 147 | + * types of methods. Existential types with wildcard type syntax such as `List[_]`, |
| 148 | + * or `Map[String, _]` are not affected. |
| 149 | + * |
| 150 | + * '''Why keep the feature?''' Existential types are needed to make sense of Java’s wildcard |
| 151 | + * types and raw types and the erased types of run-time values. |
| 152 | + * |
| 153 | + * '''Why control it?''' Having complex existential types in a code base usually makes |
| 154 | + * application code very brittle, with a tendency to produce type errors with |
| 155 | + * obscure error messages. Therefore, going overboard with existential types |
| 156 | + * is generally perceived not to be a good idea. Also, complicated existential types |
| 157 | + * might be no longer supported in a future simplification of the language. |
| 158 | + * |
| 159 | + * @group production |
| 160 | + */ |
| 161 | + @volatile implicit lazy val existentials: existentials = languageFeature.existentials |
| 162 | + |
| 163 | + /** The experimental object contains features that have been recently added but have not |
| 164 | + * been thoroughly tested in production yet. |
| 165 | + * |
| 166 | + * Experimental features '''may undergo API changes''' in future releases, so production |
| 167 | + * code should not rely on them. |
| 168 | + * |
| 169 | + * Programmers are encouraged to try out experimental features and |
| 170 | + * [[http://issues.scala-lang.org report any bugs or API inconsistencies]] |
| 171 | + * they encounter so they can be improved in future releases. |
| 172 | + * |
| 173 | + * @group experimental |
| 174 | + */ |
| 175 | + object experimental { |
| 176 | + |
| 177 | + import languageFeature.experimental._ |
| 178 | + |
| 179 | + /** Where enabled, macro definitions are allowed. Macro implementations and |
| 180 | + * macro applications are unaffected; they can be used anywhere. |
| 181 | + * |
| 182 | + * '''Why introduce the feature?''' Macros promise to make the language more regular, |
| 183 | + * replacing ad-hoc language constructs with a general powerful abstraction |
| 184 | + * capability that can express them. Macros are also a more disciplined and |
| 185 | + * powerful replacement for compiler plugins. |
| 186 | + * |
| 187 | + * '''Why control it?''' For their very power, macros can lead to code that is hard |
| 188 | + * to debug and understand. |
| 189 | + */ |
| 190 | + @volatile implicit lazy val macros: macros = languageFeature.experimental.macros |
| 191 | + } |
| 192 | + |
| 193 | + /** Where imported, a backwards compatibility mode for Scala2 is enabled */ |
| 194 | + object Scala2 |
| 195 | + |
| 196 | + /** Where imported, auto-tupling is disabled */ |
| 197 | + object noAutoTupling |
| 198 | +} |
0 commit comments