That would definitely be possible. But it isn’t likely to happen. It would make the rule several times more complicated that it currently is, to fix something that only happens occasionally, is caught at compile time, and is easily taken care of with an explicit type conversion. That doesn’t sound like the kind of tradeoff that would be accepted in Go.
One issue is that the type of the expression would change depending on what CPU the program is being compiled for. I don’t think that happens anywhere else in Go, except when using build tags. Andy > On Dec 6, 2018, at 8:45 AM, Michel Levieux <m.levi...@capitaldata.fr> wrote: > > 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 > <mailto: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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
