Skip to content

Commit a618133

Browse files
oderskyodersky
committed
WIP
1 parent 86520a7 commit a618133

File tree

3 files changed

+245
-101
lines changed

3 files changed

+245
-101
lines changed

‎docs/docs/reference/features-classification.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
layout: doc-page
33
title: A Classification of Proposed Language Features
4-
date: February 28, 2019
4+
date: April 6, 2019
55
author: Martin Odersky
66
---
77

‎docs/docs/reference/overview-old.md

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
layout: doc-page
3+
title: "Overview"
4+
---
5+
6+
This section gives an overview of the most important language additions in Dotty.
7+
It classifies features into eight groups: (1) essential foundations, (2) simplifications, (3) restrictions, (4) dropped features, (5) changed features, (6) new features, (7) features oriented towards meta-programming with the aim to replace existing macros, and (8) changes to type checking and inference.
8+
9+
The new features address four major concerns:
10+
11+
- [Consistency](http://dotty.epfl.ch/docs/reference/overview.html#consistency) - improve orthogonality and eliminate restrictions.
12+
- [Safety](http://dotty.epfl.ch/docs/reference/overview.html#safety) - enable precise domain modeling and safe refactoring.
13+
- [Ergonomics](http://dotty.epfl.ch/docs/reference/overview.html#ergonomics) - support readable and concise code.
14+
- [Performance](http://dotty.epfl.ch/docs/reference/overview.html#performance) - remove performance penalties for high-level code.
15+
16+
Scala 3 also drops a number of features that were used rarely, or where experience showed
17+
that they tended to cause problems. These are listed separately in the [Dropped Features](http://dotty.epfl.ch/docs) section.
18+
19+
Another important set of changes is about meta programming and generative programming. So far these have relied on a [macro system](https://docs.scala-lang.org/overviews/macros/overview.html) that had experimental status. This macro system will be replaced with a different solution that extends [principled meta programming](http://dotty.epfl.ch/docs/reference/other-new-features/principled-meta-programming.html) and [inline](http://dotty.epfl.ch/docs/reference/other-new-features/inline.html) definitions with some reflective capabilities. The current state of the full design and its ramifications for generative programming will be described elsewhere.
20+
21+
<a name="consistency"></a>
22+
## Consistency
23+
24+
The primary goal of the language constructs in this section is to make the language more consistent, both internally, and in relationship to its [foundations](http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.html).
25+
26+
- [Intersection types](http://dotty.epfl.ch/docs/reference/new-types/intersection-types.html) `A & B`
27+
28+
They replace compound types `A with B` (the old syntax is kept for the moment but will
29+
be deprecated in the future). Intersection types are one of the core features of DOT. They
30+
are commutative: `A & B` and `B & A` represent the same type.
31+
32+
- [Context query types](http://dotty.epfl.ch/docs/reference/contextual/query-types.html) `given A => B`.
33+
34+
Methods and lambdas can have implicit parameters, so it's natural to extend the
35+
same property to function types. context query types help ergonomics and performance
36+
as well. They can replace many uses of monads, offering better composability and an order of magnitude improvement in runtime speed.
37+
38+
- [Dependent function types](http://dotty.epfl.ch/docs/reference/new-types/dependent-function-types.html) `(x: T) => x.S`.
39+
40+
The result type of a method can refer to its parameters. We now extend the same capability
41+
to the result type of a function.
42+
43+
- [Trait parameters](http://dotty.epfl.ch/docs/reference/other-new-features/trait-parameters.html) `trait T(x: S)`
44+
45+
Traits can now have value parameters, just like classes do. This replaces the more complex [early initializer](http://dotty.epfl.ch/docs/reference/dropped-features/early-initializers.html) syntax.
46+
47+
- Generic tuples
48+
49+
([Pending](https://github.com/lampepfl/dotty/pull/2199)) Tuples with arbitrary numbers of elements are treated as sequences of nested pairs. E.g. `(a, b, c)` is shorthand for `(a, (b, (c, ())))`. This lets us drop the current limit of 22 for maximal tuple length and it allows generic programs over tuples analogous to what is currently done for `HList`.
50+
51+
<a name="safety"></a>
52+
## Safety
53+
54+
Listed in this section are new language constructs that help precise, typechecked domain modeling and that improve the reliability of refactorings.
55+
56+
- [Union types](http://dotty.epfl.ch/docs/reference/new-types/union-types.html) `A | B`
57+
58+
Union types gives fine-grained control over the possible values of a type.
59+
A union type `A | B` states that a value can be an `A` or a `B` without having
60+
to widen to a common supertype of `A` and `B`. Union types thus enable more
61+
precise domain modeling. They are also very useful for interoperating with
62+
Javascript libraries and JSON protocols.
63+
64+
- [Multiversal Equality](http://dotty.epfl.ch/docs/reference/contextual/multiversal-equality.html)
65+
66+
Multiversal equality is an opt-in way to check that comparisons using `==` and
67+
`!=` only apply to compatible types. It thus removes the biggest remaining hurdle
68+
to type-based refactoring. Normally, one would wish that one could change the type
69+
of some value or operation in a large code base, fix all type errors, and obtain
70+
at the end a working program. But universal equality `==` works for all types.
71+
So what should conceptually be a type error would not be reported and
72+
runtime behavior might change instead. Multiversal equality closes that loophole.
73+
74+
- Restrict Implicit Conversions
75+
76+
([Pending](https://github.com/lampepfl/dotty/pull/4229))
77+
Implicit conversions are very easily mis-used, which makes them the cause of much surprising behavior.
78+
We now require a language feature import not only when an implicit conversion is defined
79+
but also when it is applied. This protects users of libraries that define implicit conversions
80+
from being bitten by unanticipated feature interactions.
81+
82+
- Null safety
83+
84+
(Planned) Adding a `null` value to every type has been called a "Billion Dollar Mistake"
85+
by its inventor, Tony Hoare. With the introduction of union types, we can now do better.
86+
A type like `String` will not carry the `null` value. To express that a value can
87+
be `null`, one will use the union type `String | Null` instead. For backwards compatibility and Java interoperability, selecting on a value that's possibly `null` will still be permitted but will have a declared effect that a `NullPointerException` can be thrown (see next section).
88+
89+
- Effect Capabilities
90+
91+
(Planned) Scala so far is an impure functional programming language in that side effects
92+
are not tracked. We want to put in the hooks to allow to change this over time. The idea
93+
is to treat effects as capabilities represented as implicit parameters. Some effect types
94+
will be defined by the language, others can be added by libraries. Initially, the language
95+
will likely only cover exceptions as effect capabilities, but this can be extended later
96+
to mutations and other effects. To ensure backwards compatibility, all effect
97+
capabilities are initially available in `Predef`. Un-importing effect capabilities from
98+
`Predef` will enable stricter effect checking, and provide stronger guarantees of purity.
99+
100+
<a name="ergonomics"></a>
101+
## Ergonomics
102+
103+
The primary goal of the language constructs in this section is to make common programming patterns more concise and readable.
104+
105+
- [Enums](http://dotty.epfl.ch/docs/reference/enums/enums.html) `enum Color { case Red, Green, Blue }`
106+
107+
Enums give a simple way to express a type with a finite set of named values. They
108+
are found in most languages. The previous encodings of enums as library-defined types
109+
were not fully satisfactory and consequently were not adopted widely. The new native `enum` construct in Scala is quite flexible; among others it gives a more concise way to express [algebraic data types](http://dotty.epfl.ch/docs/reference/enums/adts.html).
110+
Scala enums will interoperate with the host platform. They support multiversal equality
111+
out of the box, i.e. an enum can only be compared to values of the same enum type.
112+
113+
- [Type lambdas](http://dotty.epfl.ch/docs/reference/new-types/type-lambdas.html) `[X] => C[X]`
114+
115+
Type lambdas were encoded previously in a roundabout way, exploiting
116+
loopholes in Scala's type system which made it Turing complete. With
117+
the removal of [unrestricted type projection](dropped-features/type-projection.html), the loopholes are eliminated, so the
118+
previous encodings are no longer expressible. Type lambdas in the language provide
119+
a safe and more ergonomic alternative.
120+
121+
- Extension clauses `extension StringOps for String { ... }`
122+
123+
([Pending](https://github.com/lampepfl/dotty/pull/4114)) Extension clauses allow to define extension methods and late implementations
124+
of traits via instance declarations. They are more readable and convey intent better
125+
than the previous encodings of these features through implicit classes and value classes.
126+
Extensions will replace implicit classes. Extensions and opaque types together can
127+
replace almost all usages of value classes. Value classes are kept around for the
128+
time being since there might be a new good use case for them in the future if the host platform supports "structs" or some other way to express multi-field value classes.
129+
130+
<a name="performance"></a>
131+
## Performance
132+
133+
The primary goal of the language constructs in this section is to enable high-level, safe code without having to pay a performance penalty.
134+
135+
- [Opaque Type Aliases](https://dotty.epfl.ch/docs/reference/other-new-features/opaques.html) `opaque type A = T`
136+
137+
An opaque alias defines a new type `A` in terms of an existing type `T`. Unlike the previous modeling using value classes, opaque types never box. Opaque types are described in detail in [SIP 35](https://docs.scala-lang.org/sips/opaque-types.html).
138+
139+
- [Erased parameters](http://dotty.epfl.ch/docs/reference/other-new-features/erased-terms.html)
140+
141+
Parameters of methods and functions can be declared `erased`. This means that
142+
the corresponding arguments are only used for type checking purposes and no code
143+
will be generated for them. Typical candidates for erased parameters are type
144+
constraints such as `=:=` and `<:<` that are expressed through implicits.
145+
Erased parameters improve both run times (since no argument has to be constructed) and compile times (since potentially large arguments can be eliminated early).
146+
147+
See also: [A classification of proposed language features](./features-classification.html)

0 commit comments

Comments
 (0)