This topic is well explained in the blog post at blog.golang.org/constants,
if I do say so myself.
-rob
On Thu, Jan 28, 2021 at 4:45 PM Arunkumar Gudelli <
arunkumar.gude...@gmail.com> wrote:
> 256 considered as `constant`. (untyped)
> So when we try to convert to byte (which has a range from 0
256 considered as `constant`. (untyped)
So when we try to convert to byte (which has a range from 0 to 255), it
will throw the overflow error.
Where `x := uint64(256)` we are giving a type to constant uint64.
y := byte(256) // Same error
so byte(uint64) will be zero without any errors.
regards,
On Wed, Jan 27, 2021 at 5:13 PM Barry Li wrote:
>
> Some doubts about type conversion in go.
> In the following code, why can it be executed normally after passing the
> variable?
> The code is an error during the compilation phase.
>
> // The following two lines of code can be executed normally
Some doubts about type conversion in go.
In the following code, why can it be executed normally after passing the
variable?
The code is an error during the compilation phase.
// The following two lines of code can be executed normally
x := uint64(256)
fmt.Println(byte(uint64(x))) // norma
On Wed, Jan 27, 2021 at 1:10 PM clément auger wrote:
>
> I am wondering if some backward compatibility is planned for programs heavily
> relying
> on ast, parser, type, packages packages to analyze, interpret, manipulate go
> source code.
>
> I read this morning the blog and it says
> 'The langu
Programs written against a current Go version should continue to work
indefinitely.
So, yes, if you don't want to take advantage of generics (or other Go 2
changes), you don't have to do any work to have your program continue to
work. That's why I don't like the "Go 2" label - there just won't be a
Hello,
I am wondering if some backward compatibility is planned for programs
heavily relying
on *ast, parser, type, packages* packages to analyze, interpret, manipulate
go source code.
I read this morning the blog and it says
'The language changes are fully backward compatible' in its last ne
> Note, that this is essentially one of the workflows suggested here (which I
> would consider the canonical documentation for the "eng org wants to onboard
> Go" case):
> https://golang.org/ref/mod#private-modules
I have realised a goproxy may be needed rather than a http server as I expect a
d
