You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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
changed the title
proposal: spec: allow unary + on string
proposal: Go 2: spec: allow unary + on string
Sep 13, 2018
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:
Note that the following contracts are currently equivalent:
If someone wants an obvious "I want to allow numeric addition and not concatenation", they can much more explicitly say it like so:
Solution
This is what the following is said by the spec:
I propose it be changed to something similar to the following:
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.
The text was updated successfully, but these errors were encountered: