Fork of daniellemaywood.uk/gleam — Wasm codegen work
1<!--
2 SPDX-License-Identifier: Apache-2.0
3 SPDX-FileCopyrightText: 2025 The Gleam contributors
4-->
5
6# Breaking changes to make for v2
7
8## `[1 ..]` syntax
9
10Due to a bug in the parser we accept `[1, ..]` as a valid list value.
11
12- [x] Emits warning when used.
13- [x] Formatter rewrites it to desired syntax.
14
15## `_ as a` syntax
16
17This pattern doesn't make sense as one could write `a` instead. We don't want
18two ways of doing the same thing.
19
20- [x] Emits warning when used.
21- [x] Formatter rewrites it to desired syntax.
22
23## Shadowing imported values
24
25Do not allow shadowing an imported value, the same way one can't define two
26top level functions with the same name.
27
28- [x] Emits warning when used.
29
30## Import one module multiple times
31
32Do not allow one module to be imported multiple times. This is currently
33accepted so long as each import uses a different alias.
34
35- [x] Emits warning when used.
36
37## JavaScript runtime error `fn` property
38
39On JavaScript there is a deprecated `fn` property. This was a mistake, it
40should have been `function`. It still exists today due to backwards
41compatibility.
42
43## Do not allow guard with no condition
44
45It doesn't make sense to have an `if` guard followed by no condition, but the
46compiler allows this: `case wibble { big if -> True }`
47
48- [x] Emits warning when used.
49- [x] Formatter rewrites it to desired syntax.
50
51## Piping into a call that returns a function
52
53In Gleam v1, the syntax `a |> b(c)` is ambiguous; it can either mean `b(a, c)`
54or `b(a)(c)`. This makes code harder to reason about as it means that you cannot
55determine the meaning of pipe expressions without knowing the type of the called
56function.
57
58In Gleam v2, we want to remove the second option, so `a |> b(c)` always desugars
59to `b(a, c)`, regardless of the types.
60
61- [x] Emits warning when used.
62- [x] Code action to rewrite to desired syntax