Would it be possible in the future that the compiler holds a set of the possible types for a given untyped value, and assigns it the "minimum" type if int does not belong to the possible ones? this holds only for integer types of course. In the current example we'd have :
1 << 64 - 1 is integer so it should be int 1 << 64 - 1 has possible types uint (on a 64 bits machine) and uint64 - therefore int does not belong to the set of possible types, uint is the "minimum" type it can take --> when used, 1 << 64 - 1 takes type uint by default (on a 64 bits machine - otherwise it would take uint64) Le jeu. 6 déc. 2018 à 03:15, Louki Sumirniy < louki.sumirniy.stal...@gmail.com> a écrit : > The implicit type inferred from an integer is always 'int'. This is a 64 > bit signed integer and thus has a maximum width of 63 bits. In Go, you > should not assume sign or width of an untyped implicit conversion, as the > 'int' and 'uint' types default to the size of processor registers, which > are 64 bits. Making this assumption will have undefined results depending > on the platform. > > I'm not sure why it works now but I encountered this problem with > cross-compilation, as the program had an `int` that was assumed to be over > 32 bits long and it refused to compile. It appears to me that there must > have been a recent change to implement 64 bit integers on 32 bit platforms. > > I have a general policy with integers and Go, if I know it might be bigger > than 32 bits, I specify the type. If it's a simple counter and unlikely to > get anywhere near this, I can leave out the type spec. Also, to reduce > confusion and ambiguity, if I am using shift operators I also specify > unsigned. On the hardware level, most platforms are implementing bitshifts > with multiplication. But sometimes not, also. The reason to use >> and << > should be to use, if available, the hardware's shift operator, as it > otherwise falls back to multiplication. > > On Wednesday, 5 December 2018 17:36:32 UTC+1, Michel Levieux wrote: >> >> Hi guys, >> >> With a colleague of mine, we've run into a strange issue today. When we >> look at package math, in const.go, we can see this line : >> >> MaxUint64 = 1<<64 - 1 >>> >>> >> which I assume works pretty well. But if I do the same in a test main and >> try to 'go run' it, with this line : >> >> const v = 1 << 64 - 1 >>> >>> >> I get the following error : >> >> ./testmain.go:8:13: constant 18446744073709551615 overflows int >>> >> >> I think this is not a bug and we're just missing something here. Could >> anyone explain this behaviour / point me to a documentation that explains >> it? >> >> Thank you guys >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
