<!-- SPDX-License-Identifier: Apache-2.0 SPDX-FileCopyrightText: 2025 The Gleam contributors -->

Breaking changes to make for v2

[1 ..] syntax

Due to a bug in the parser we accept [1, ..] as a valid list value.

• Emits warning when used.
• Formatter rewrites it to desired syntax.

_ as a syntax

This pattern doesn't make sense as one could write a instead. We don't want two ways of doing the same thing.

• Emits warning when used.
• Formatter rewrites it to desired syntax.

Shadowing imported values

Do not allow shadowing an imported value, the same way one can't define two top level functions with the same name.

• Emits warning when used.

Import one module multiple times

Do not allow one module to be imported multiple times. This is currently accepted so long as each import uses a different alias.

• Emits warning when used.

JavaScript runtime error fn property

On JavaScript there is a deprecated fn property. This was a mistake, it should have been function. It still exists today due to backwards compatibility.

Do not allow guard with no condition

It doesn't make sense to have an if guard followed by no condition, but the compiler allows this: case wibble { big if -> True }

• Emits warning when used.
• Formatter rewrites it to desired syntax.

Piping into a call that returns a function

In Gleam v1, the syntax a |> b(c) is ambiguous; it can either mean b(a, c) or b(a)(c). This makes code harder to reason about as it means that you cannot determine the meaning of pipe expressions without knowing the type of the called function.

In Gleam v2, we want to remove the second option, so a |> b(c) always desugars to b(a, c), regardless of the types.

• Emits warning when used.
• Code action to rewrite to desired syntax