Allow negating all number literals

[giacomocavalieri]

Hello! I'd like to start a discussion about this so we can come up with a design.

What's the issue

Today the compiler allows negating literal integer and floats, but doesn't support negating integer literal expressed using the 0x, 0o and 0b syntax:

pub fn main() {
  echo -1.    // ✅ works
  echo -1.1   // ✅ works
  echo -0b11  // ❌ compilation error
  echo -0o12  // ❌ compilation error
  echo -0x12  // ❌ compilation error
}

I think this is confusing and feels like an overlooked case rather than an intentional decision. I think it would be much nicer if all of the examples above were correctly parsed as a negated number.

So what is going on today

At the moment an expression like -0o12 is parsed as -0 followed by the o12 variable. I feel like this is never what someone wants. So much so that the Gleam tree sitter grammar highlights the whole -0b12 as a single literal numbers, and not as a number followed by an identifier.

Why is this a breaking change

Changing the compiler to correctly parse the negated literal would technically be a breaking change. For example this function would start returning -1 instead of 11:

pub fn a_number() -> Int {
  let b1 = 11
  -0b1
}

In gleam 1.x this returns 11 as the compiler sees it as:

pub fn a_number() -> Int {
  let b1 = 11
  -0
  b1
}

With this proposed change it would instead be a regular negated literal: -0b1, that is -1.

I can't come up with any other piece of code that would be affected by this change, and I believe this kind of code is extremely unlikely to ever exist in any normal codebase:

• It results in a warning, because the -0 part is always ignored:

  warning: Unused literal
     ┌─ /src/main.gleam:12:3
     │
  12 │   -0b1
     │   ^^ This value is never used
  
  Hint: You can safely remove it.
  

• The formatter changes it to:

  pub fn a_number() -> Int {
    -0
    b1
  }

  Which makes it plenty clear this is not what one meant by writing -0b1

Are there other pieces of code that would be affected by this change? Is this change desired at all if we ever were to make it v2?

[AmaroMiranda]

This proposed change in Gleam's compiler behavior addresses an inconsistency: currently, negative decimal literals like -1 are parsed correctly, but -0b11, -0o12, and -0x12 fail due to being misinterpreted as -0 followed by an identifier. The suggestion is to treat all these as single negated literals, which aligns better with user expectations and grammar highlighters like Tree-sitter.

Why this matters:
Improves clarity & consistency

Fixes unintuitive edge cases

May break rare existing code, but:

Such code likely never worked as intended

Emits compiler warnings

Gets reformatted clearly by the Gleam formatter