We do this in the runtime:

const PtrSize = 4 << (^uintptr(0) >> 63)           // unsafe.Sizeof(uintptr(0)) but an ideal const

You could do a similar thing with int/uint and then write your abs using that constant.

const intBits = 4 + 4*(^uint(0)>>63)
func abs(n int) int {
	y := n >> (intBits - 1)
	return (n ^ y) - y
}

For what it's worth, we can see 32-bit vs. 64-bit in runtime/lfstack_32bit.go vs. runtime/lfstack_64bit.go and in runtime/hash32.go vs. runtime/hash64.go.

I'm not against this proposal, but the given example doesn't motivate me. With build tags you have to write each function twice. With appropriate constants you only have to write them once.
(Or you use the build tags to just define the constant, which seems overkill.)

Also see #29982, which saves you from computing the sizes yourself.

@randall77 My point here is that writing an optimised function twice might be exactly what you're after. Using a type-specific constant could be a possible solution, but might not always work.

@smasher164 That's a good suggestion. It's a bit unfortunate that the proposal wasn't considered yet, but math/bits.UintSize might be good enough for this use case. It still wouldn't address cases where clever bit twiddling and shifting by a constant solves the problem.

Let me see if I can come up with an example where constants won't work.

If you have a constant you can always write two different implementations if you want. Either:

func f() {
    if intSize == 64 {
        ... implementation 1 ...
    } else {
        ... implementation 2 ...
    }
}

or

func f() {
    if intSize == 64 {
        f64()
    } else {
        f32()
    }
}
func f64() {
    ... implementation 1 ...
}
func f32() {
    ... implementation 2 ...
}

Either way if intSize is a constant the wrapping gets completely compiled away.

Unfortunately, this does not apply to numeric literals:

package main
import "testing"
const intSize = 4 + (^uint(0)>>63) * 4
func TestInt(t *testing.T) {
	var v []int
	if intSize == 8 {
		v = []int{ -0x7ffffffffffffffe, 0x7ffffffffffffffe, -0x7fffffffffffffff, 0x7fffffffffffffff }
	} else {
		v = []int{ -0x7ffffffe, 0x7ffffffe, -0x7fffffff, 0x7fffffff }
	}
	t.Logf("intSize=%d v[0]=%d", intSize, v[0])
}

will produce the following, when compiled on 32bit:

./int_test.go:7:14: constant -9223372036854775806 overflows int
./int_test.go:7:35: constant 9223372036854775806 overflows int
./int_test.go:7:55: constant -9223372036854775807 overflows int
./int_test.go:7:76: constant 9223372036854775807 overflows int

@onitake, the way to avoid that issue is typically to write constants like intSize that serve as masks and then mask the values. Or in this case:

const maxInt = 1<<(intSize*8-1) - 1
v := []int{-(maxInt-1), maxInt-1, -maxInt, maxInt}

It's not ideal but it doesn't come up too often and is much lower complexity to maintain than separate files with separate build tags.

🤔 Hmmmmm... I suppose I can do it this way.

I still think it's overly cryptic and counter-intuitive, though.

Issue #28538 suggested adding math.MaxInt etc and was accepted but never implemented for Go 1.13. It is still open and can be implemented for Go 1.14. Assuming that does happen, then the solution to #33388 (comment) is to use those named constants.

Given the multiple (and usually much better) ways to write 32- or 64-bit specific code, it seems like adding build tags is heavy-weight and redundant. It seems like we should decline adding build tags based on architecture size.

Any thoughts?

It might depend on the perspective, but 32/64 bit build tags don't seem particularly "heavy-weight" to me...
But I understand the reluctance to add additional features without a good reason, particularly if there is an alternative solution.

For the reasons in the past two comments, in the absence of a common use case where the build tag is the best way to engineer the split, this issue seems to be a likely decline.

Leaving open for a week for final comments.

Marked this last week as likely decline w/ call for last comments (#33388 (comment)).
Declining now.