You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/manual/generalized-algebraic-data-types.mdx
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,6 +34,7 @@ type timezone =
34
34
Using this variant type, we will end up having functions like this:
35
35
36
36
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
37
+
37
38
```res
38
39
let convertToDaylight = tz => {
39
40
switch tz {
@@ -49,6 +50,7 @@ This function is only valid for a subset of our variant type's constructors but
49
50
Let's see if we can find a way for the compiler to help us with normal variants. We could define another variant type to distinguish the two kinds of timezone.
50
51
51
52
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
53
+
52
54
```res
53
55
type daylightOrStandard =
54
56
| Daylight(timezone)
@@ -58,6 +60,7 @@ type daylightOrStandard =
58
60
This has a lot of problems. For one, it's cumbersome and redundant. We would now have to pattern-match twice whenever we deal with a timezone that's wrapped up here. The compiler will force us to check whether we are dealing with daylight or standard time, but notice that there's nothing stopping us from providing invalid timezones to these constructors:
59
61
60
62
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
63
+
61
64
```res
62
65
let invalidTz1 = Daylight(EST)
63
66
let invalidTz2 = Standard(EDT)
@@ -82,6 +85,7 @@ We define our type with a type parameter. We manually annotate each constructor,
82
85
but we've added another level of specificity using a type parameter. Constructors are now understood to be `standard` or `daylight` at the _type_ level. Now we can fix our function like this:
83
86
84
87
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
88
+
85
89
```res
86
90
let convertToDaylight = tz => {
87
91
switch tz {
@@ -97,6 +101,7 @@ we try to return a standard timezone from this function. Actually, this seems li
97
101
we still want to be able to match on all cases of the variant sometimes, and a naive attempt at this will not pass the type checker. A naive example will fail:
98
102
99
103
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
104
+
100
105
```res
101
106
let convertToDaylight = tz =>
102
107
switch tz {
@@ -110,6 +115,7 @@ let convertToDaylight = tz =>
110
115
This will complain that `daylight` and `standard` are incompatible. To fix this, we need to explicitly annotate to tell the compiler to accept both:
111
116
112
117
{/* TODO: fix this example, it has an error because it doesn't have access to the previous snippet */}
118
+
113
119
```res
114
120
let convertToDaylight : type a. timezone<a> => timezone<daylight> = // ...
115
121
```
@@ -124,6 +130,7 @@ Sometimes, a function should have a different return type based on what you give
124
130
[^1]: In ReScript v12, the built-in operators are already generic, but we use them in this example for simplicity.
125
131
126
132
{/* this example purposefully has an error so it is not marked as an example */}
133
+
127
134
```res
128
135
type rec number<_> = Int(int): number<int> | Float(float): number<float>
129
136
@@ -212,6 +219,7 @@ depending on which event we are binding to. A naive implementation might look si
212
219
separate method for each stream event to wrap the unsafe version of `on`.
213
220
214
221
{/* TODO: fix this example, it has an error */}
222
+
215
223
```res
216
224
module Stream = {
217
225
type t
@@ -242,6 +250,7 @@ follow how the type variables are getting filled in, write it out on paper what
0 commit comments