Re: [go-nuts] Strange behaviour of left shift

[Andy Balholm]

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  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  > 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 
> .

-- 
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.

Re: [go-nuts] Strange behaviour of left shift

[Michael Jones]

Another way of saying it: "Go has Schrödinger's Constants." This captures
the notion that a constant is of every type until you use it, whereupon it
settles to the appropriate type based on the expectations of the use site.

On Wed, Dec 5, 2018 at 2:55 PM Rob Pike  wrote:

> Most of this is explained in blog.golang.org/constants.
>
> -rob
>
>
> On Thu, Dec 6, 2018 at 4:04 AM Andy Balholm  wrote:
>
>> When an untyped integer constant is converted to a typed value, it always
>> becomes int. I suppose the rules could be made more complicated to handle
>> values that won’t fit in an int. But what if the value is too big to fit in
>> a uint64? Should it be a float64 then?
>>
>> Andy
>>
>> On Dec 5, 2018, at 8:54 AM, Michel Levieux 
>> wrote:
>>
>> Well the only thing I do in the main is :
>>
>> fmt.Println(v)
>>>
>>
>> Shouldn't the compiler statically type v to uint64?
>> I don't get the need to force type of v to uint64?
>>
>> Le mer. 5 déc. 2018 à 17:45, Andy Balholm  a
>> écrit :
>>
>>> Apparently in your code the value is being assigned to an int. But it’s
>>> too large for an int; it needs a uint64 to hold it.
>>>
>>> Andy
>>>
>>> On Dec 5, 2018, at 8:35 AM, 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.
>>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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.

Re: [go-nuts] Strange behaviour of left shift

[Rob Pike]

Most of this is explained in blog.golang.org/constants.

-rob


On Thu, Dec 6, 2018 at 4:04 AM Andy Balholm  wrote:

> When an untyped integer constant is converted to a typed value, it always
> becomes int. I suppose the rules could be made more complicated to handle
> values that won’t fit in an int. But what if the value is too big to fit in
> a uint64? Should it be a float64 then?
>
> Andy
>
> On Dec 5, 2018, at 8:54 AM, Michel Levieux 
> wrote:
>
> Well the only thing I do in the main is :
>
> fmt.Println(v)
>>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
>
> Le mer. 5 déc. 2018 à 17:45, Andy Balholm  a
> écrit :
>
>> Apparently in your code the value is being assigned to an int. But it’s
>> too large for an int; it needs a uint64 to hold it.
>>
>> Andy
>>
>> On Dec 5, 2018, at 8:35 AM, 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.
>

-- 
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.

Re: [go-nuts] Strange behaviour of left shift

[Andy Balholm]

When an untyped integer constant is converted to a typed value, it always 
becomes int. I suppose the rules could be made more complicated to handle 
values that won’t fit in an int. But what if the value is too big to fit in a 
uint64? Should it be a float64 then?

Andy

> On Dec 5, 2018, at 8:54 AM, Michel Levieux  wrote:
> 
> Well the only thing I do in the main is :
> 
> fmt.Println(v)
> 
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
> 
> Le mer. 5 déc. 2018 à 17:45, Andy Balholm  > a écrit :
> Apparently in your code the value is being assigned to an int. But it’s too 
> large for an int; it needs a uint64 to hold it.
> 
> Andy
> 
>> On Dec 5, 2018, at 8:35 AM, 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.

Re: [go-nuts] Strange behaviour of left shift

[James Bardin]

On Wednesday, December 5, 2018 at 11:55:25 AM UTC-5, Michel Levieux wrote:
>
> Well the only thing I do in the main is :
>
> fmt.Println(v)
>>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
>
>
Nope. You're passing an untyped constant into an `interface{}`, so the 
compiler needs to pick a type from the specified defaults:

> The default type of an untyped constant is bool, rune, int, float64, 
complex128 or string respectively,

https://golang.org/ref/spec#Constants

-- 
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.

Re: [go-nuts] Strange behaviour of left shift

[Burak Serdar]

On Wed, Dec 5, 2018 at 9:55 AM Michel Levieux  wrote:
>
> Well the only thing I do in the main is :
>
>> fmt.Println(v)
>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?


v is an untyped constant. When passed to Println, it is an int.

var x uint64
var y int64

x=v // ok
y=v // not ok

>
> Le mer. 5 déc. 2018 à 17:45, Andy Balholm  a écrit :
>>
>> Apparently in your code the value is being assigned to an int. But it’s too 
>> large for an int; it needs a uint64 to hold it.
>>
>> Andy
>>
>> On Dec 5, 2018, at 8:35 AM, 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.

-- 
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.

Re: [go-nuts] Strange behaviour of left shift

[Michel Levieux]

Well the only thing I do in the main is :

fmt.Println(v)
>

Shouldn't the compiler statically type v to uint64?
I don't get the need to force type of v to uint64?

Le mer. 5 déc. 2018 à 17:45, Andy Balholm  a écrit :

> Apparently in your code the value is being assigned to an int. But it’s
> too large for an int; it needs a uint64 to hold it.
>
> Andy
>
> On Dec 5, 2018, at 8:35 AM, 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.

Re: [go-nuts] Strange behaviour of left shift

[Andy Balholm]

Apparently in your code the value is being assigned to an int. But it’s too 
large for an int; it needs a uint64 to hold it.

Andy

> On Dec 5, 2018, at 8:35 AM, 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.

[go-nuts] Strange behaviour of left shift

[Michel Levieux]

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.