[go-nuts] Re: Is it possible to export a variable from main package? If impossible, why?
OK. Now I understand. Thanks for all replies.
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
Kazuya,
That makes no sense.
The main package is the point of entry to an executable. This is where
things happen.
You create packages that are able to do things and you use them in the main
package to some purpose.
It's going against to the reason why packages are there.
What you're asking is like saying that you want to make your Image
Processing library depend on your program, when the program should depend
on the library
On Thu, Jan 24, 2019 at 4:00 PM 伊藤和也 wrote:
> Is it possible?
>
> package main
>
> var Number int = 100
> func main() {}
>
>
> package hello
>
> import "fmt"
>
> func abc() {
>fmt.Println(Number)
> }
>
> 2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>>
>> package main
>>
>> var Number int = 100
>>
>> func main() {
>>
>> }
>>
>> --
> 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] Re: Is it possible to export a variable from main package? If impossible, why?
On Thu, Jan 24, 2019, at 07:00, 伊藤和也 wrote:
> Is it possible?
> package main
>
> var Number int = 100
> func main() {}
>
> package hello
>
> import "fmt"
>
> func abc() {
>fmt.Println(Number)
> }2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
> > package main
> >
> > var Number int = 100
> >
> > func main() {
> >
> > }
No, if you simply try this you'll see that you get an error:
import "main" is a program, not an importable package
—Sam
--
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] How to debug goroutine with dlv
When i debug go func() with dlv, use s to go into but not exec.
Who is familiar with dlv debugging go source code？
thanks！
package main
import "fmt"
func main() {
a := make(chan int)
go func() {
a <- 1
}()
for {
select {
case i, ok := <-a:
fmt.Println("a:", i, "\tStatus:", ok)
default:
fmt.Println("a over")
return
}
}
}
go build -o chan -gcflags="-N -l" chan.go
dlv exec ./chan
Type 'help' for list of commands.
(dlv) b main.main:7
Command failed: could not find
/data/app/go/src/go1.11.1/demo/type/chan/debug/chan.go:12
(dlv) b main.main
Breakpoint 1 set at 0x1090fc8 for main.main() ./chan.go:5
(dlv) c
> main.main() ./chan.go:5 (hits goroutine(1):1 total:1) (PC: 0x1090fc8)
1: package main
2:
3: import "fmt"
4:
=> 5: func main() {
6: a := make(chan int)
7: go func() {
8: a <- 1
9: }()
10:
(dlv) s
> main.main() ./chan.go:6 (PC: 0x1090fdf)
1: package main
2:
3: import "fmt"
4:
5: func main() {
=> 6: a := make(chan int)
7: go func() {
8: a <- 1
9: }()
10:
11: for {
(dlv) s
> main.main() ./chan.go:9 (PC: 0x1091002)
4:
5: func main() {
6: a := make(chan int)
7: go func() {
8: a <- 1
=> 9: }()
10:
11: for {
12: select {
13: case i, ok := <-a:
14: fmt.Println("a:", i, "\tStatus:", ok)
(dlv)
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
Is it possible?
package main
var Number int = 100
func main() {}
package hello
import "fmt"
func abc() {
fmt.Println(Number)
}
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
The question is what you are trying to accomplish - if you want two main
packages share variables you could make a third package and have both main
packages import that.
/M
Den 24. jan. 2019 kl. 07.40 skrev 伊藤和也
mailto:kazya.ito.dr...@gmail.com>>:
What Francisco Dalla Rosa Soares says is right. I only compiled "b.go". Is it
possible to import "main" package to other packages except "main"?
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
package main
var Number int = 100
func main() {
}
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
What Francisco Dalla Rosa Soares says is right. I only compiled "b.go". Is
it possible to import "main" package to other packages except "main"?
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
Are you compiling both files together?
a.go
package main
var Number int
-
---b.go
package main
import "fmt"
func main() {
Number = 1
fmt.Println(Number)
}
-
go build a.go b.go
On Thu, Jan 24, 2019 at 3:16 PM Michael Banzon wrote:
> Can you provide the output you get and the source you are compiling?
>
> If you could also include the command line input+output it would probably
> help.
>
> /M
>
> Den 24. jan. 2019 kl. 07.13 skrev 伊藤和也 :
>
> Now I tried to use "Number" in the same package "main" in a different .go
> file in the same directly but I got the compile error "undefined: Number".
>
>
> 2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>>
>> package main
>>
>> var Number int = 100
>>
>> func main() {
>>
>> }
>>
>> --
> 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] Re: Is it possible to export a variable from main package? If impossible, why?
Can you provide the output you get and the source you are compiling?
If you could also include the command line input+output it would probably help.
/M
Den 24. jan. 2019 kl. 07.13 skrev 伊藤和也
mailto:kazya.ito.dr...@gmail.com>>:
Now I tried to use "Number" in the same package "main" in a different .go file
in the same directly but I got the compile error "undefined: Number".
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
package main
var Number int = 100
func main() {
}
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
Now I tried to use "Number" in the same package "main" in a different .go
file in the same directly but I got the compile error "undefined: Number".
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
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] Re: Is it possible to export a variable from main package? If impossible, why?
packages have nothing to do with files, if you are on some directory you
don't need to import any package, just use Number on other files
On Thu, Jan 24, 2019, 3:36 AM 伊藤和也 wrote:
> I couldn't import "main" package to other packages to use the variable
> "Number" and I try to use "Number" in main package of different .go file
> in the same directory but I couldn't.
>
> 2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>>
>> package main
>>
>> var Number int = 100
>>
>> func main() {
>>
>> }
>>
>> --
> 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] Re: Is it possible to export a variable from main package? If impossible, why?
I couldn't import "main" package to other packages to use the variable
"Number" and I try to use "Number" in main package of different .go file
in the same directory but I couldn't.
2019年1月24日木曜日 11時27分57秒 UTC+9 伊藤和也:
>
> package main
>
> var Number int = 100
>
> func main() {
>
> }
>
>
--
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] Is it possible to export a variable from main package? If impossible, why?
Yes, you can export a variable from the main package. It's not very useful, since normally nothing will import the package, but you can do it if you want. Ian -- 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] Re: why map the key type must not be a function, map, or slice
thanks lan.
在 2019年1月23日星期三 UTC+8下午11:26:57，Ian Lance Taylor写道：
>
> On Tue, Jan 22, 2019 at 11:47 PM >
> wrote:
> >
> > i got :
> > # command-line-arguments
> > ./key.go:6:18: invalid operation: F() == F() (func can only be compared
> to nil)
>
> Yes, that is what the language spec says and it is what I said: in Go,
> function values are not comparable.
>
> I wrote that code as an example to help explain why function values
> are not comparable.
>
> Ian
>
> > 在 2019年1月23日星期三 UTC+8上午11:59:07，mount...@gmail.com写道：
> >>
> >> When i use the func, map slice as the key of map, it isn't work!
> >> So I lookup source why, i find
> >>
> >> // spec: "The comparison operators == and != must be fully defined
> >> // for operands of the key type; thus the key type must not be
> a
> >> // function, map, or slice."
> >> //
> >> // Delay this check because it requires fully setup types;
> >> // it is safe to continue in any case (was issue 6667).
> >> check.later(func() {
> >> if !Comparable(typ.key) {
> >> check.errorf(e.Key.Pos(), "invalid map key type %s",
> typ.key)
> >> }
> >> })
> >> // Comparable reports whether values of type T are comparable.
> >> func Comparable(T Type) bool {
> >> switch t := T.Underlying().(type) {
> >> case *Basic:
> >> // assume invalid types to be comparable
> >> // to avoid follow-up errors
> >> return t.kind != UntypedNil
> >> case *Pointer, *Interface, *Chan:
> >> return true
> >> case *Struct:
> >> for _, f := range t.fields {
> >> if !Comparable(f.typ) {
> >> return false
> >> }
> >> }
> >> return true
> >> case *Array:
> >> return Comparable(t.elem)
> >> }
> >> return false
> >> }
> >
> > --
> > 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...@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] Is it possible to export a variable from main package? If impossible, why?
package main
var Number int = 100
func main() {
}
--
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] Re: [golang-dev] Re: [security] Go 1.11.5 and Go 1.10.8 are released
Got it, thanks. On Wed, Jan 23, 2019 at 6:41 PM Julie Qiu wrote: > > We will not be updating the archives for this release. The reason is because > these directories do not affect functionality, and we do not want to risk the > availability of the security release, nor we want to change the contents of > already published archives. > > Julie > > On Wed, Jan 23, 2019 at 8:00 PM andrey mirtchovski > wrote: >> >> sorry to be a bother, but are you publishing new archives? will you >> publish new hashes for the archives with the commands executed thusly? >> >> On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu wrote: >> > >> > Hello gophers, >> > >> > Due to an issue with the release tooling (https://golang.org/issue/29906), >> > go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two >> > unnecessary directories in the root of the archive: "gocache" and "tmp". >> > >> > They are harmless and safe to remove. >> > >> > The following commands can be used to extract only the necessary “go” >> > directory from the archives: >> > >> > tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go >> > tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go >> > >> > >> > These commands will create a Go tree in /usr/local/go. >> > >> > Sorry for the inconvenience, >> > Julie (on behalf of the Go team) >> > >> > On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu wrote: >> >> >> >> Hi gophers, >> >> >> >> We have just released Go 1.11.5 and Go 1.10.8 to address a recently >> >> reported security issue. We recommend that all users update to one of >> >> these releases (if you’re not sure which, choose Go 1.11.5). >> >> >> >> This DoS vulnerability in the crypto/elliptic implementations of the >> >> P-521 and P-384 elliptic curves may let an attacker craft inputs that >> >> consume excessive amounts of CPU. >> >> >> >> These inputs might be delivered via TLS handshakes, X.509 certificates, >> >> JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH >> >> private key is reused more than once, the attack can also lead to key >> >> recovery. >> >> >> >> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the >> >> Go issue for more details. >> >> >> >> Downloads are available at https://golang.org/dl for all supported >> >> platforms. >> >> >> >> Cheers, >> >> >> >> Julie (on behalf of the Go team) >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "golang-dev" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to golang-dev+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] Re: [golang-dev] Re: [security] Go 1.11.5 and Go 1.10.8 are released
We will not be updating the archives for this release. The reason is because these directories do not affect functionality, and we do not want to risk the availability of the security release, nor we want to change the contents of already published archives. Julie On Wed, Jan 23, 2019 at 8:00 PM andrey mirtchovski wrote: > sorry to be a bother, but are you publishing new archives? will you > publish new hashes for the archives with the commands executed thusly? > > On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu wrote: > > > > Hello gophers, > > > > Due to an issue with the release tooling (https://golang.org/issue/29906), > go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two > unnecessary directories in the root of the archive: "gocache" and "tmp". > > > > They are harmless and safe to remove. > > > > The following commands can be used to extract only the necessary “go” > directory from the archives: > > > > tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go > > tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go > > > > > > These commands will create a Go tree in /usr/local/go. > > > > Sorry for the inconvenience, > > Julie (on behalf of the Go team) > > > > On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu wrote: > >> > >> Hi gophers, > >> > >> We have just released Go 1.11.5 and Go 1.10.8 to address a recently > reported security issue. We recommend that all users update to one of these > releases (if you’re not sure which, choose Go 1.11.5). > >> > >> This DoS vulnerability in the crypto/elliptic implementations of the > P-521 and P-384 elliptic curves may let an attacker craft inputs that > consume excessive amounts of CPU. > >> > >> These inputs might be delivered via TLS handshakes, X.509 certificates, > JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH > private key is reused more than once, the attack can also lead to key > recovery. > >> > >> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See > the Go issue for more details. > >> > >> Downloads are available at https://golang.org/dl for all supported > platforms. > >> > >> Cheers, > >> > >> Julie (on behalf of the Go team) > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-dev+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] Re: [golang-dev] Re: [security] Go 1.11.5 and Go 1.10.8 are released
sorry to be a bother, but are you publishing new archives? will you publish new hashes for the archives with the commands executed thusly? On Wed, Jan 23, 2019 at 5:12 PM Julie Qiu wrote: > > Hello gophers, > > Due to an issue with the release tooling (https://golang.org/issue/29906), > go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two > unnecessary directories in the root of the archive: "gocache" and "tmp". > > They are harmless and safe to remove. > > The following commands can be used to extract only the necessary “go” > directory from the archives: > > tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go > tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go > > > These commands will create a Go tree in /usr/local/go. > > Sorry for the inconvenience, > Julie (on behalf of the Go team) > > On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu wrote: >> >> Hi gophers, >> >> We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported >> security issue. We recommend that all users update to one of these releases >> (if you’re not sure which, choose Go 1.11.5). >> >> This DoS vulnerability in the crypto/elliptic implementations of the P-521 >> and P-384 elliptic curves may let an attacker craft inputs that consume >> excessive amounts of CPU. >> >> These inputs might be delivered via TLS handshakes, X.509 certificates, JWT >> tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private >> key is reused more than once, the attack can also lead to key recovery. >> >> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go >> issue for more details. >> >> Downloads are available at https://golang.org/dl for all supported platforms. >> >> Cheers, >> >> Julie (on behalf of the Go team) > > -- > You received this message because you are subscribed to the Google Groups > "golang-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-dev+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] Gse v0.30.0 is released, Go efficient text segmentation, add hmm support
Go efficient text segmentation; support english, chinese, japanese and other. https://github.com/go-ego/gse/releases/tag/0.30.0 -- 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] Re: [security] Go 1.11.5 and Go 1.10.8 are released
Hello gophers, Due to an issue with the release tooling (https://golang.org/issue/29906), go1.11.5.linux-amd64.tar.gz and go1.10.8.linux-amd64.tar.gz include two unnecessary directories in the root of the archive: "gocache" and "tmp". They are harmless and safe to remove. The following commands can be used to extract only the necessary “go” directory from the archives: tar -C /usr/local -xzf go1.11.5.linux-amd64.tar.gz go tar -C /usr/local -xzf go1.10.8.linux-amd64.tar.gz go These commands will create a Go tree in /usr/local/go. Sorry for the inconvenience, Julie (on behalf of the Go team) On Wed, Jan 23, 2019 at 4:53 PM Julie Qiu wrote: > Hi gophers, > > We have just released Go 1.11.5 and Go 1.10.8 to address a recently > reported security issue. We recommend that all users update to one of these > releases (if you’re not sure which, choose Go 1.11.5). > > This DoS vulnerability in the crypto/elliptic implementations of the P-521 > and P-384 elliptic curves may let an attacker craft inputs that consume > excessive amounts of CPU. > > These inputs might be delivered via TLS handshakes, X.509 certificates, > JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH > private key is reused more than once, the attack can also lead to key > recovery. > > The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the > Go issue for more details. > > Downloads are available at https://golang.org/dl for all supported > platforms. > > Cheers, > > Julie (on behalf of the Go team) > -- 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] Re: [security] Go 1.11.5 and Go 1.10.8 are released
The release tarballs include two new directories: "gocache" and "tmp". Any special reason for that? -- 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] [security] Go 1.11.5 and Go 1.10.8 are released
Hi gophers, We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.11.5). This DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU. These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery. The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go issue for more details. Downloads are available at https://golang.org/dl for all supported platforms. Cheers, Julie (on behalf of the Go team) -- 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] "All types implement the empty interface"
* 伊藤和也 [190123 00:27]:
> I found the explanation "All types implement the empty interface".
> https://golang.org/ref/spec#Interface_types
> So an empty interface also implements an empty interface? and again the
> empty interface implements an empty interface and the empty inter...
> What I imagine is like this below.
> :
> :
> :
>empty interface
> |
>empty interface
> |
>empty interface
> || |
>int float64 bool
>
> In java, Object class is the top.
>
> Object
> |
> Creture
> ||
> Animal Human
>| |
> Dog Cat
Francisco's answer is very good, but I think there is a lot of confusion
over variables of an interface type containing values of another
interface type. This does not happen. When assigning a value X of an
interface type A to a variable Y of another interface type B, only the
dynamic type of X is retained in Y. The variable Y contains no
information that the value assigned to it was previously held in a
variable of type A (i.e. had a different interface type).
The dynamic type of an interface value is NEVER an interface type.
Repeat the above statement over and over until it sinks in.
At https://golang.org/ref/spec#Variables the spec defines the dynamic
type of an interface variable as "the concrete type of the value
assigned to the variable at run time", but it never defines the term
"concrete type". The approximate definition of "concrete type" (and
thus "dynamic type") is the underlying non-interface type of the value.
This definition is implied by the fact that there is no way to create a
value of an interface type (other than nil, which is given as an
explicit exception in the definition of "dynamic type") except by
assignment from a type that implements the interface. The type of the
value being assigned is either an interface type or a non-interface
type.
If it is an interface type, this is a recursive definition, so the
dynamic type of the result of the assignment must be the dynamic type of
the value being assigned. Keep recursing on this until the value being
assigned is not an interface type, and you end up with the implication
that the dynamic type must be a non-interface type.
To be pedantic, Jan's answer is wrong. Instances do not implement
interfaces, types do (both interface and concrete types).
Note under https://golang.org/ref/spec#Interface_types the statement
"Such a type is said to implement the interface". Also note that the
assignability rules only make sense if you are talking about the type of
a value.
The following would not be legal if an interface type could not
implement another interface type (because the instance of «a» cannot be
known at compile time, at least not easily in a more complicated example
where the value of a is the result of invoking a function from another
package):
https://play.golang.org/p/DBj6Jczj3OM
type A interface {
foo()
goo()
}
type B interface {
foo()
}
type X struct {}
func (x X) foo() {}
func (x X) goo() {}
var a A = X{}
var b B = a
...Marvin
--
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] Re: why map the key type must not be a function, map, or slice
On Tue, Jan 22, 2019 at 11:47 PM wrote:
>
> i got :
> # command-line-arguments
> ./key.go:6:18: invalid operation: F() == F() (func can only be compared to
> nil)
Yes, that is what the language spec says and it is what I said: in Go,
function values are not comparable.
I wrote that code as an example to help explain why function values
are not comparable.
Ian
> 在 2019年1月23日星期三 UTC+8上午11:59:07，mount...@gmail.com写道：
>>
>> When i use the func, map slice as the key of map, it isn't work!
>> So I lookup source why, i find
>>
>> // spec: "The comparison operators == and != must be fully defined
>> // for operands of the key type; thus the key type must not be a
>> // function, map, or slice."
>> //
>> // Delay this check because it requires fully setup types;
>> // it is safe to continue in any case (was issue 6667).
>> check.later(func() {
>> if !Comparable(typ.key) {
>> check.errorf(e.Key.Pos(), "invalid map key type %s", typ.key)
>> }
>> })
>> // Comparable reports whether values of type T are comparable.
>> func Comparable(T Type) bool {
>> switch t := T.Underlying().(type) {
>> case *Basic:
>> // assume invalid types to be comparable
>> // to avoid follow-up errors
>> return t.kind != UntypedNil
>> case *Pointer, *Interface, *Chan:
>> return true
>> case *Struct:
>> for _, f := range t.fields {
>> if !Comparable(f.typ) {
>> return false
>> }
>> }
>> return true
>> case *Array:
>> return Comparable(t.elem)
>> }
>> return false
>> }
>
> --
> 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] Golang net/http server returning empty packets
Thanks for the suggestions. Sadly, the race detection doesn't work on ARM
platforms. I'll try adding tracing as you suggest and see what comes of it.
On Tuesday, 22 January 2019 16:18:17 UTC, robert engels wrote:
>
> Sounds a lot like a concurrency issue - possibly not flushing the request,
> or the request is being processed / timing out from another go routine. I
> would start by adding some lifecycle request traces and processing these in
> an automated fashion - almost the only way to debug highly concurrent
> issues.
>
> Also, did you try running the server with “race detection” turned on -
> this might be your best and easiest bet.
>
> On Jan 22, 2019, at 9:52 AM, Tom Cook >
> wrote:
>
> I have a moderately complex HTTP server written using net/http
> HandlerFuncs. Testing one request at a time all is well, but when I start
> putting significant load on it, it sometimes returns empty packets, ie no
> HTTP response headers, no status code, nothing. The clients are all
> written using Python requests and report BadstatusLine("").
>
> I don't have a straightforward way of reproducing this without all the
> relevant software (and indeed hardware) being configured, and it's still
> possible that there is some code path through my code that ends without
> writing anything into the HttpResponse, though I have spent quite a few
> hours reviewing the code for this possibility and can't see how it would
> happen.
>
> Does anyone know if there are conditions where the net/http server can do
> this? The load during system startup might be considered high, but it's
> maybe ten requests per second high, not thousands, though the hardware is
> relatively limited (think RPi2 and you're not too far wrong). I'm using a
> custom mux, but it's a copy-and-paste of net/http.ServeMux with some extra
> logging added.
>
> Thanks for any help,
> Tom
>
>
> --
> 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...@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] GitHub go-formal ownership
(Pardon, please ignore the previous message, it should have been private.) Le mer. 23 janv. 2019 à 13:58, Marko Ristin-Kaufmann a écrit : > Hi Scott, > Could you describe a bit in more detail what needs to be done and how > often? Are there any knowledge requirements? > > I already develop github.com/Parquery/gocontracts and I am quite > interested in the topic so I might be a potential candidate. > > Cheers Marko > > Le mer. 23 janv. 2019 à 10:20, Scott Cotton a écrit : > >> Hello Gophers, >> >> Some time ago, I started the go-formal github organisation as a place for >> formal analysis tools in and for Go. >> >> I am looking for a volunteer to take over ownership of the github >> organisation go-formal as I will be unable to that role starting >> in the coming weeks. >> >> The administrative overhead of this role is so far quite minimal while I >> think it's a very good thing to have a place for such tools >> in Go. >> >> As a reminder to those who might be wondering "formal analysis tools" is >> somewhat open ended in scope but to the current maintainer refers to tools >> the likes of which can be found in many conference tool papers such as CAV, >> FMCAD, POPL, etc, as well as many other languages (CBMC, ...) which >> involve formal logic. >> >> Some ideas came to mind for folks who might be interested in becoming >> the github go-formal owner (in no particular order): >> 1. Alan Donavan of the golang analysis packages. >> 2. GopherSat authors. >> 3. Others who have worked on formal projects in Go but less visibly. >> 4. go-critic and staticcheck.io authors. >> >> Please do feel free to contact me off-line or here on go-nuts for details. >> >> Best, >> Scott >> >> -- >> 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] GitHub go-formal ownership
Hi Scott, Could you describe a bit in more detail what needs to be done and how often? Are there any knowledge requirements? I already develop github.com/Parquery/gocontracts and I am quite interested in the topic so I might be a potential candidate. Cheers Marko Le mer. 23 janv. 2019 à 10:20, Scott Cotton a écrit : > Hello Gophers, > > Some time ago, I started the go-formal github organisation as a place for > formal analysis tools in and for Go. > > I am looking for a volunteer to take over ownership of the github > organisation go-formal as I will be unable to that role starting > in the coming weeks. > > The administrative overhead of this role is so far quite minimal while I > think it's a very good thing to have a place for such tools > in Go. > > As a reminder to those who might be wondering "formal analysis tools" is > somewhat open ended in scope but to the current maintainer refers to tools > the likes of which can be found in many conference tool papers such as CAV, > FMCAD, POPL, etc, as well as many other languages (CBMC, ...) which > involve formal logic. > > Some ideas came to mind for folks who might be interested in becoming the > github go-formal owner (in no particular order): > 1. Alan Donavan of the golang analysis packages. > 2. GopherSat authors. > 3. Others who have worked on formal projects in Go but less visibly. > 4. go-critic and staticcheck.io authors. > > Please do feel free to contact me off-line or here on go-nuts for details. > > Best, > Scott > > -- > 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] Re: What does "nil implay?
On Wednesday, 23 January 2019 13:31:13 UTC+1, Victor Giordano wrote: > > You wrote > > >> All nil values are perfectly defined: they are the zero value of the >> particular type. > > > As i see things the nil is the *default value* for the pointers. If you > want to call it "zero value" to the default is up to, for me doesn't work > like that. For me "zero" (0) is a value and "nil" is another value. > The term "zero value" in regard to Go's types and values is *not* subject to discussion, personal opinion or taste but has a defined meaning: It is a specified technical term. Please take some minutes and look it up in the language spec. The term "the zero value of type X" has a defined meaning and must not be conflated with the integer literal 0. If you want to discuss physics you have to stick your meaning of "energy" or "momentum" to the official technical terms if you want to be taken serious. V. > -- 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] Re: What does "nil implay?
On Wed, Jan 23, 2019 at 1:30 PM Victor Giordano wrote: > You wrote > > All nil values are perfectly defined: they are the zero value of the particular type. > > As i see things the nil is the default value for the pointers. If you want to call it "zero value" to the default is up to, for me doesn't work like that. For me "zero" (0) is a value and "nil" is another value. > > Hope you get what i'm saying. No I don't, sorry. Zero (0) is a number. Numbers (types int, intNN, float32, ...) cannot have a nil value. I don't understand how numbers got involved in this discussion about nil values. They're not related. But some types allow nil values (chan T, []T, ...). Nil values of such types are equal to the zero value of that type. So nil values are well defined. -- -j -- 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] Why not a mixture of value and pointer receiver?
Thanks Ivan. Good to know this. So the answer to my question is just about, like Ian said, confusion for readers? Am Mi., 23. Jan. 2019 um 12:15 Uhr schrieb Ivan Fraixedes : > Perhaps > > There is a handy exception, though. When the value is addressable, the >> language takes care of the common case of invoking a pointer method on a >> value by inserting the address operator automatically. In our example, the >> variable b is addressable, so we can call its Write method with just >> b.Write. The compiler will rewrite that to ().Write for us. > > > clarifies your confusion. > > You can find such paragraph in > https://golang.org/doc/effective_go.html#pointers_vs_values > > On Wednesday, 23 January 2019 09:52:02 UTC+1, Xinhu Liu wrote: >> >> Why is that a problem? I can indeed call it on value (at line 20). I got >> result: >>> >>> hello >>> hello >>> Program exited. >>> >>> >> I am now more confusing when I come to >> https://golang.org/doc/faq#different_method_sets. >> >> Am Mi., 23. Jan. 2019 um 06:47 Uhr schrieb Andrei Avram < >> andrei.a...@gmail.com>: >> >>> If it's about a method you've defined on a pointer and you want to call >>> it on the value: https://play.golang.org/p/zMVivcaXrf3 >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/xOsuXPe1IUo/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/xOsuXPe1IUo/unsubscribe. > To unsubscribe from this group and all its topics, 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] Re: What does "nil implay?
You wrote > All nil values are perfectly defined: they are the zero value of the > particular type. As i see things the nil is the *default value* for the pointers. If you want to call it "zero value" to the default is up to, for me doesn't work like that. For me "zero" (0) is a value and "nil" is another value. Hope you get what i'm saying. -- 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] Re: What does "nil implay?
On Wed, Jan 23, 2019 at 1:09 PM Victor Giordano wrote: > 0 != nil I don't understand what is has to do with what I wrote. Your example is not a valid Go expression. Not all types have nil values. Let me reiterate: A nil value of a type is always equal to the zero value of that type. Because zero value of a type is well defined, a nil value of a type is also well defined. -- -j -- 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] Re: What does "nil implay?
0 != nil El mié., 23 ene. 2019 a las 9:08, Jan Mercl (<0xj...@gmail.com>) escribió: > On Wed, Jan 23, 2019 at 12:45 PM Victor Giordano > wrote: > > >> All nil values are perfectly defined: they are the zero value of the > particular type. > > > > Just to point.. .zero is value different that nil. > > Not sure what's meant by this. When is a nil value of a type different > from its zero value? > > -- > > -j > -- 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] Re: What does "nil implay?
On Wed, Jan 23, 2019 at 12:45 PM Victor Giordano wrote: >> All nil values are perfectly defined: they are the zero value of the particular type. > > Just to point.. .zero is value different that nil. Not sure what's meant by this. When is a nil value of a type different from its zero value? -- -j -- 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] Re: What does "nil implay?
El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió: > > On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote: > > > From a language specific level (higher abstraction) is means undefined, > is the absence of a value. > > No value in Go can _not_ have a value. > > > Something whose value is nil/null/undefined is not defined. > > All nil values are perfectly defined: they are the zero value of the > particular type. > Just to point.. .zero is value different that nil. > > -- > > -j > -- 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] Re: What does "nil implay?
I was giving an interpretaion about the meaning of nil from different pespectives El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió: > > On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote: > > > From a language specific level (higher abstraction) is means undefined, > is the absence of a value. > > No value in Go can _not_ have a value. > > > Something whose value is nil/null/undefined is not defined. > > All nil values are perfectly defined: they are the zero value of the > particular type. > > -- > > -j > -- 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] Why not a mixture of value and pointer receiver?
Perhaps There is a handy exception, though. When the value is addressable, the > language takes care of the common case of invoking a pointer method on a > value by inserting the address operator automatically. In our example, the > variable b is addressable, so we can call its Write method with just > b.Write. The compiler will rewrite that to ().Write for us. clarifies your confusion. You can find such paragraph in https://golang.org/doc/effective_go.html#pointers_vs_values On Wednesday, 23 January 2019 09:52:02 UTC+1, Xinhu Liu wrote: > > Why is that a problem? I can indeed call it on value (at line 20). I got > result: >> >> hello >> hello >> Program exited. >> >> > I am now more confusing when I come to > https://golang.org/doc/faq#different_method_sets. > > Am Mi., 23. Jan. 2019 um 06:47 Uhr schrieb Andrei Avram < > andrei.a...@gmail.com >: > >> If it's about a method you've defined on a pointer and you want to call >> it on the value: https://play.golang.org/p/zMVivcaXrf3 >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/xOsuXPe1IUo/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@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] GitHub go-formal ownership
Hello Gophers, Some time ago, I started the go-formal github organisation as a place for formal analysis tools in and for Go. I am looking for a volunteer to take over ownership of the github organisation go-formal as I will be unable to that role starting in the coming weeks. The administrative overhead of this role is so far quite minimal while I think it's a very good thing to have a place for such tools in Go. As a reminder to those who might be wondering "formal analysis tools" is somewhat open ended in scope but to the current maintainer refers to tools the likes of which can be found in many conference tool papers such as CAV, FMCAD, POPL, etc, as well as many other languages (CBMC, ...) which involve formal logic. Some ideas came to mind for folks who might be interested in becoming the github go-formal owner (in no particular order): 1. Alan Donavan of the golang analysis packages. 2. GopherSat authors. 3. Others who have worked on formal projects in Go but less visibly. 4. go-critic and staticcheck.io authors. Please do feel free to contact me off-line or here on go-nuts for details. Best, Scott -- 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] Why not a mixture of value and pointer receiver?
Why is that a problem? I can indeed call it on value (at line 20). I got result: > > hello > hello > Program exited. > > I am now more confusing when I come to https://golang.org/doc/faq#different_method_sets. Am Mi., 23. Jan. 2019 um 06:47 Uhr schrieb Andrei Avram < andrei.avram@gmail.com>: > If it's about a method you've defined on a pointer and you want to call it > on the value: https://play.golang.org/p/zMVivcaXrf3 > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/xOsuXPe1IUo/unsubscribe. > To unsubscribe from this group and all its topics, 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] Why not a mixture of value and pointer receiver?
On the other side maybe confusion on the part of code writers if they use pointer receiver because of consistency instead of needing it? Am Mi., 23. Jan. 2019 um 00:01 Uhr schrieb Ian Lance Taylor : > On Tue, Jan 22, 2019 at 1:59 PM Xinhu Liu wrote: > > > > In "A Tour of Go" I read: > > > >> In general, all methods on a given type should have either value or > pointer receivers, but not a mixture of both. > > > > > > But why not? > > > > Methods having value receiver can be called by both value type and > pointer type. The same is for methods having pointer receiver. > > > > What is disadvantages of mixing value and pointer receiver? > > Confusion on the part of the code reader. > > Ian > -- 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.
