Topic/language features #85
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
Add a method "featureEnabled" that checks whether a feature is enabled. Features can be enabled by imports or by command-line options. The Scala 2.10 way of enabling features by implicits got dropped, because the use of the feature mechanism is now different. Previously, features imposed restrictions on what used to work. So it was important to offer way to avoid the restrictions it that was as smooth as possible, and implicits fit the bill. Furthermore, features did not change the way things were compiled, so it was OK to test them only once all types were compiled. Now, features are essentially switches that change compile time behavior. keepUnions and noAutoTupling, if on, will modify the way type inference works. So we need to interprete a switch on the spot, and doing an implicit search to determine a switch value is too dangerous in what concerns causing cyclic references. At the same time, because we are dealing with new functionality, there is less of a concern for being able to set or reset features for large pieces of code with some implicit. You could argue that's not even desirable, and that an explicit import or command line option is preferable. Conflicts: src/dotty/tools/dotc/core/SymDenotations.scala
Auto-tupling should satisfy the following spec. 1. An application `f(args)` where `f` is a non-overloaded method which has a single, non-repeated parameter as its first parameter list and where args consists of two or more arguments is expanded to `f((args))`. 2. A constructor pattern `C(args)` where `C.unapply` is a non-overloaded method which has a single, non-repeated parameter as its first parameter list and where args consists of two or more arguments is expanded to `C((args))`. Auto-tupling can be disabled by language feature "noAutoTupling". Conflicts: test/dotc/tests.scala
Eliminated all "Dotty deviations" which were due to lack of auto-tupling.
Introduce new cases for AndTypes and OrTypes in methods `derivesFrom`, `baseClasses`, and `baseTypeWithArgs`. These cases are ultimately needed so that `baseTypeWithArgs` makes sense for union and intersection types. Also, fixed embarrassing typo in method `TypeBounds#|`.
Use the equality (where ~ is any form of refinement)
T1 { x ~ R1 } & T2 { x ~ R2 } == T1 & T2 { x ~ R1 & R2 }
We already did the same thing when distributing via "&".
Appromiximate union types by intersections of their common base classes. Controlled by option -Xkeep-unions. If option is set, no approximation is done. Motivations for approximating: There are two. First, union types are departure from Scala 2. From time to time they lead to failure of inference. One example experiences in Dotty was in a foldLeft, where the accumulator type was inferred to be Tree before and was now a union of two tree specific kinds. Tree was the correct type, whereas the union type was too specific. These failures are not common (in the Dotty codebase there were 3, I believe), but they cause considerable difficulty to diagnose. So it seems safer to have a compatibility mode with Scala 2. The second motivation is that union types can become large and unwieldy. A function like TreeCopier has a result type consisting of ~ 40 alternatives, where the alternative type would be just Tree. Once we gain more experience with union types, we might consider flipping the option, and making union types the default. But for now it is safer this way, I believe.
Removed annotations from the dotty codebase that were necessary because the inferred union types caused inference errors later on.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I took into account the comments by @DarkDimius.
Review and sheparding by @DarkDimius, please.