Shouldn't the pointer arithmetic operators be eg `&+` rather than `+`?

Evolution Discussion
1

Shouldn't the pointer arithmetic operators be &+, &- and &+= and &-= instead of the current:

public static func + (lhs: UnsafeMutableRawPointer, rhs: Int) -> UnsafeMutableRawPointer

public static func + (lhs: Int, rhs: UnsafeMutableRawPointer) -> UnsafeMutableRawPointer

public static func - (lhs: UnsafeMutableRawPointer, rhs: Int) -> UnsafeMutableRawPointer

public static func - (lhs: UnsafeMutableRawPointer, rhs: UnsafeMutableRawPointer) -> Int

public static func += (lhs: inout UnsafeMutableRawPointer, rhs: Int)

public static func -= (lhs: inout UnsafeMutableRawPointer, rhs: Int)

They are masking operators after all, not performing any overflow check, as expected. But their current names/symbols suggests otherwise.

2

If you're using the pointer arithmetic operations in a way that wraps around the address space you've already invoked undefined behavior. The types having "Unsafe" in the name is enough to signify that. So while the operators are not performing any checks, neither are they guaranteed to be safe like &+ et al.

3

I'm not sure what you mean by not guaranteed to be safe like &+, of course everything is unsafe that has to do with UnsafePointers ... I was just thinking that it would be more consistent to name them &+ etc since + might lead people (that are used to &+ and + for fixed width integers) to wonder if there is a performance overhead for an overflow check when they use + on their pointer.

But I get the point about pointer arithmetic being something entirely different than fixed width integer arithmetic. And people should of course be able to trust Swift's Standard Library not to introduce performance overhead by checking for overflow when doing pointer arithmetic. (Although I think I did see + and * being used instead of &+ and &* for an offset or count somewhere in the implementation of Swift's Pointer API …)