Go: proposal: Go 2: spec: allow unary + on string

[deanveloper]

Problem

Especially with generics coming up where operators become important, the following contracts are different, even though they may look like they are the same:

contract UnaryAdd(a A) {
    +a
}
contract BinaryAdd(a A) {
    a+a
}

Note that the following contracts _are_ currently equivalent:

contract UnarySub(a A) {
    -a
}
contract BinarySub(a A) {
    a-a
}

If someone wants an obvious "I want to allow numeric addition and not concatenation", they can much more explicitly say it like so:

contract NumericAdd(a A) {
    0 + a
}

Solution

This is what the following is said by the spec:

For integer operands, the unary operators +, -, and ^ are defined as follows:

+x                          is 0 + x
-x    negation              is 0 - x
^x    bitwise complement    is m ^ x  with m = "all bits set to 1" for unsigned x
                                      and  m = -1 for signed x

I propose it be changed to something similar to the following:

For all operands, the unary operators +, -, and ^ are defined as follows:

+x                          is z + x
-x    negation              is z - x
^x    bitwise complement    is m ^ x

where z is the zero value for the type of x
and m is "all bits set to 1" for unsigned x and -1 for signed x

Impact

This would have an extremely small impact on _programming_ in Go, but in _contract-writing_ this could hide away one of those "weird cases". It prevents a library writer from seeing this case and using +a to mean "numeric addition only" in a contract, which may not be immediately obvious to a reader.

This also means that in the future of Go, if more types (ie matrices) are added, if binary operators defined on them, the unary operators will also be defined on them. Even though this is unlikely, I think it's a good thing to add.

This is also a very small change, and should be Go 1 compatible. This needs to have a decision either with or before Go 2 though, because of contract equivalence.

[mvdan]

/cc @griesemer @ianlancetaylor

[mvdan]

I realise that you've said this should happen along with or before contracts, but we default to placing all language changes into Go2. Remember that generics is also part of the broader Go2, even if it ends up being just Go 1.19 or whichever incremental version.

[griesemer]

This seems like a fine idea to finesse this specific problem with contracts. But we should wait and see what the final contracts design is going to be and whether we actually need this.

[ianlancetaylor]

Thanks for the suggestion. Let's close this specific issue in favor of the general discussion about generics and contracts.