Literal definitions stranges

Literal definition of signed literals have unary - for describe sign of number. As I think literal is udivide by parts for compiler, but I have example than broke this logic:

(-1i128).pow(-number as u32 + 1) * fib.value

Than I remove braces from -1i128 compile interpret this expression as:

-(1i128.pow(-number as u32 + 1)) * fib.value

I think it’s strange for perception.

A simpler example is -1i8.abs() vs (-1i8).abs(). This difference is kind of annoying given that -1i8 is seen as a literal by the macro system:

macro_rules! yes_this_is_a_literal {
    ($val:literal) => ();

Changing this would be a breaking change for Rust though…

1 Like

I uderstand about breaking, but I think the simplifying syntax is better than less changes.

Rust has strong guarantees about breaking changes, so we can’t make a breaking change for this (it is not unsound behavior).


So, it may be added to rust 2019 edition, or another future proposals.

1 Like

For this to happen in an edition, it would need a lint warning about the change in behaviour. So if you wanted to make progress towards it, consider writing a lint – which may be valuable regardless of whether a change happens if people consider -1i8.abs() confusing.

(I don’t know the rules for clippy vs rustc here.)

I believe - should be part of the integer literal, not a tack-on token. Esp. in light of what @mjbshaw wrote - it IS a literal, so why the minus sign is treated separately?

Can somebody describe the necessary steps for writing such a lint in more detail so that we could implement it and add to rustc (or clippy? not sure) so it can be made part of some edition. I would love to see this changed in a further edition to a more sane semantics where -1u8.abs() returns 1 not -1.

I’ve proposed to add a note about this to the book:

1 Like

clippy::precedence covers the problem with negative literals:


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.