[SOLVED] `abs(_:)` returns negative numbers in Int extension

[tem (GalaxySwift)]

Pretty sure this is a bug:

extension Int {
  func f() -> Int {
    return abs(self)
  }
}

print(abs(-1))  //  1
print(-1.f())   // -1

SwiftFiddle link:

Swift Online Playground

But I'm curious about what's happening here.

The extension function returns -1 even if I use a negative literal abs(-1) instead of abs(self).

[1-877-547-7272]

It seems that print(-1.f()) is being parsed as print(-(1.f())), not print((-1).f()).

Personally, I’d expect it to parse as print((-1).f()) as well, especially given that -0x80 as Int8 is allowed but 0x80 as Int8 is not allowed. Perhaps there should be a warning about this behavior?

[tem (GalaxySwift)]

Oh, I was so focused on the abs(-1) part thanks for clearing that up! So it's not a bug after all!

I agree that the minus sign should have higher precedence as part of a literal, but perhaps that would be counterintuitive with variables and function calls.

[tera]

Yep, that's a feature. Exaggerating:

print(-1   .   f())

-1
  .f()

[1-877-547-7272]

I think there is definitely a bug in the syntax highlighter here.

If you write print(-1.f()) in Swift Playgrounds for iPad, then you’ll see that -1 is highlighted as a numeric literal, despite the fact that the - is not part of the numeric literal. The - should instead be highlighted as a function.

This even happens if you use parentheses in the expression, resulting in one parenthesis having a different color than the rest:

I haven’t tested this on my Mac yet, but it seems likely that Xcode has this bug too. Visual Studio Code’s syntax highlighter also has this bug when parentheses aren’t used, but behaves correctly when parentheses are used.

[tem (GalaxySwift)]

Well spotted!

I can confirm that Swift Playgrounds on Mac has this bug.

VS Code has it when bracket pair colorization is not enabled*, or when directly preceding the digits.

* only with certain themes: Light+ (default light) has the bug, Noctis Lux doesn't.

Xcode does not have it.

[xwu (Xiaodi Wu)]

@1-877-547-7272

If you write print(-1.f()) in Swift Playgrounds for iPad, then you’ll see that -1 is highlighted as a numeric literal, despite the fact that the - is not part of the numeric literal.

Well...it's complicated:

Negative values can be represented by prepending the hyphen-minus character ( - ). This is considered to be part of the integer literal. In other words, the expression -42 is lexed as a single value, not as a call to the prefix operator - with 42 as its operand.

By contrast, the expression -(42) is lexed as a call to the prefix operator - . The distinction can be observed when working with floating-point types that support distinct representations for +0.0 and -0.0 :

let x: Double = -0
x.sign // .plus

let y: Double = -(0)
y.sign // .minus

In the first example, a built-in integer literal is initialized to the value -0 , but integer types do not support signed zero and the sign is ignored. Then, based on the type annotation, the integer value is converted to a positive floating-point value.

In the second example, a built-in integer literal is initialized to the value 0 . Based on the type annotation, the value is converted to a positive floating-point value, then the floating-point prefix operator - is called to change the sign.

Note that the Swift standard library defines the prefix operator + for symmetry but does not consider a prepended + to be part of an integer literal. Therefore, +42 is lexed as a call to the prefix operator + with 42 as its operand.

In spite of these considerations, the member expression dot operator ( . ) binds more tightly than both the prefix operator - and the prepended literal - :

-(42.trailingZeroBitCount) // -1
(-42).trailingZeroBitCount //  1
-42.trailingZeroBitCount   // -1

(From part 1 of my series of articles on numerics in Swift.)

[1-877-547-7272]

- wouldn’t be part of the numeric literal in this context though, right?

[xwu (Xiaodi Wu)]

@1-877-547-7272

- wouldn’t be part of the numeric literal in this context though, right?

Correct—not in terms of how it behaves from the user perspective.

[tera]

@xwu

the member expression dot operator ( . ) binds more tightly than both the prefix operator

In the hindsight was it the right decision to make the precedence of prefix - lower than ".", given that there could be no space between - and 42?

    -42
       .trailingZeroBitCount

here I'm using the popular way to format chained code:

foo
   .bar()
   .baz
   .qux