[go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

[Ally Dale]

Does anyone konw which proposal changes the access for embeded field name 
of struct？
Eg:
```
type Base struct{
Name string
}
type Value struct{
Base
}
```

We initial a Value as:
var v = Value{
Base: Base{
Name:"xxx",
}
}
instead of 
var v = Value{
Name:"xxx",
}

I want to know why golang change the access method.
Anyone who knows the isssue link, please reply me. Thanks a lot.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

['Axel Wagner' via golang-nuts]

I don't understand the question. This has always been how the language
worked, all the way back to Go 1.0 at least. As far as I'm aware.

Embedding only effects selector expressions and methods sets - i.e. it
allows you to write `v.Name` instead of writing `v.Base.Name`. It doesn't
affect composite literals.

On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:

> Does anyone konw which proposal changes the access for embeded field name
> of struct？
> Eg:
> ```
> type Base struct{
> Name string
> }
> type Value struct{
> Base
> }
> ```
>
> We initial a Value as:
> var v = Value{
> Base: Base{
> Name:"xxx",
> }
> }
> instead of
> var v = Value{
> Name:"xxx",
> }
>
> I want to know why golang change the access method.
> Anyone who knows the isssue link, please reply me. Thanks a lot.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG%2B18zTbSsNq--hx%2Bqa90%3D3TLHtiviKwCd6o7fNPsDmkA%40mail.gmail.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

[Jan Mercl]

On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:

> I want to know why golang change the access method.

The name of the programming language is Go.

> Anyone who knows the isssue link, please reply me. Thanks a lot.

There's no proposal and there's no issue. It always worked like that.

You cannot initialize the field 'Name' of struct 'Value' because
struct 'Value' has no such field. The (essentially) syntactic sugar
that allows to access the inner field like in 'value.Name' is
specified to work in selectors, not in initializers:
https://golang.org/ref/spec#Selectors

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UpAQsB%2BroTxMG-w9RdSQOqHUNdWXLNT%2BCYNak5xmbicA%40mail.gmail.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

[Ally Dale]

As far as I remember(maybe I have missing something),  
var v = Value{
Name:"xxx",
}
Is the old way to initial an embeded field.
Some issuse changes the way of this.
I can't find the original discussion.

在2021年6月7日星期一 UTC+8 下午5:28:27 写道：

> I don't understand the question. This has always been how the language 
> worked, all the way back to Go 1.0 at least. As far as I'm aware.
>
> Embedding only effects selector expressions and methods sets - i.e. it 
> allows you to write `v.Name` instead of writing `v.Base.Name`. It doesn't 
> affect composite literals.
>
> On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:
>
>> Does anyone konw which proposal changes the access for embeded field name 
>> of struct？
>> Eg:
>> ```
>> type Base struct{
>> Name string
>> }
>> type Value struct{
>> Base
>> }
>> ```
>>
>> We initial a Value as:
>> var v = Value{
>> Base: Base{
>> Name:"xxx",
>> }
>> }
>> instead of 
>> var v = Value{
>> Name:"xxx",
>> }
>>
>> I want to know why golang change the access method.
>> Anyone who knows the isssue link, please reply me. Thanks a lot.
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7d00093f-0253-489e-a5c9-40eceb5b2f1bn%40googlegroups.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

['Axel Wagner' via golang-nuts]

What we are saying is that you are misremembering. That's not how Go ever
worked.

On Mon, Jun 7, 2021 at 11:36 AM Ally Dale  wrote:

> As far as I remember(maybe I have missing something),
> var v = Value{
> Name:"xxx",
> }
> Is the old way to initial an embeded field.
> Some issuse changes the way of this.
> I can't find the original discussion.
>
> 在2021年6月7日星期一 UTC+8 下午5:28:27 写道：
>
>> I don't understand the question. This has always been how the language
>> worked, all the way back to Go 1.0 at least. As far as I'm aware.
>>
>> Embedding only effects selector expressions and methods sets - i.e. it
>> allows you to write `v.Name` instead of writing `v.Base.Name`. It
>> doesn't affect composite literals.
>>
>> On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:
>>
>>> Does anyone konw which proposal changes the access for embeded field
>>> name of struct？
>>> Eg:
>>> ```
>>> type Base struct{
>>> Name string
>>> }
>>> type Value struct{
>>> Base
>>> }
>>> ```
>>>
>>> We initial a Value as:
>>> var v = Value{
>>> Base: Base{
>>> Name:"xxx",
>>> }
>>> }
>>> instead of
>>> var v = Value{
>>> Name:"xxx",
>>> }
>>>
>>> I want to know why golang change the access method.
>>> Anyone who knows the isssue link, please reply me. Thanks a lot.
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7d00093f-0253-489e-a5c9-40eceb5b2f1bn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEM2dS9YeppfqT_va%3DJRqj-9yxsbE2AfwkdfNxnar2_YA%40mail.gmail.com.

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[Ian Davis]

Would it be feasible for the Go tool to disable inlining and deadcode 
elimination of code within the bodies of Benchmarks and Tests? Not the code 
under test of course. It could be as crude as disabling these optimizations for 
files in _test.go files.



On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
> Thanks! I'd seen the "dead code elimination" comment somewhere and questioned 
> it, but not enough.
> 
> If I worry about what some future Go compiler might optimize, I end up 
> worrying quite a lot! For example, could this code:
> 
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
> 
> hypothetically be optimized to:
> 
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = PopCount(0x1234567890abcdef) * b.N
> }
> 
> since PopCount() always returns the same value for the same argument? It 
> probably wouldn't, since that would break many existing benchmarks.
> 
> Maybe more reasonably worrisome: If sum is initialized and incremented but 
> never read, could all references to it be optimized away? That's easy enough 
> to avoid, as is the optimization I worried about above:
> 
> var sum = 0 // Avoid dead code elimination
> const firstInput uint64 = 0x1234567890abcdef
> 
> func BenchmarkPopCountSimple(b *testing.B) {
> for i, input := 0, firstInput; i < b.N; i++ {
> sum += PopCount(input)
> input++
> }
> if sum == 0 {
> b.Error("BenchmarkPopCountSimple: sum == 0")
> }
> }
> 
> Here are my new benchmark results:
> 
> $ go version
> go version go1.16.5 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountSimple 2710047904.419 ns/op
> BenchmarkPopCountSlowSimple  278   4235890 ns/op
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
> 2727591344.434 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
> 1456130778.172 ns/op
> PASS
> ok  gopl.io/popcount7.061s
> 
> The anomalistically-low "simple" and "almost simple" results are now more 
> reasonable, but still nearly a factor of two lower than the "nearly simple" 
> results. They're still inlining the calls, as is the "slow simple" benchmark, 
> where the "nearly simple" one isn't:
> 
> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to PopCount'
> .\popcount_test.go:10:18: inlining call to PopCount
> .\popcount_test.go:22:19: inlining call to PopCount
> .\popcount_test.go:34:19: inlining call to PopCount
> 
> Overkill, right? --PSRC
> 
> P.S.: For better or worse, I discovered I can -- but shouldn't, based on the 
> feedback I got! -- get "fancy" formatting by copying from vscode and pasting 
> into Gmail.
> 
> 
> 
> On Tuesday, June 1, 2021 at 12:01:51 PM UTC-4 peterGo wrote:
>> Here is a more definitive reply than my original reply.
>> 
>> 
>> I got as far as this
>> func BenchmarkPopCountSimple(b *testing.B) {
>> sum := 0 // Avoid dead code elimination.
>> for i := 0; i < b.N; i++ {
>> sum += PopCount(0x1234567890abcdef)
>> }
>> }
>> 
>> As you can see from the objdump, BenchmarkPopCountSimple dead code is 
>> eliminated.
>> 
>> func BenchmarkPopCountSimple(b *testing.B) {
>>   0x4e38c031c9XORL CX, CX
>> 
>> for i := 0; i < b.N; i++ {
>>   0x4e38c2eb03JMP 0x4e38c7
>>   0x4e38c448ffc1INCQ CX
>>   0x4e38c74839889001CMPQ CX, 0x190(AX)
>>   0x4e38ce7ff4JG 0x4e38c4
>> }
>>   0x4e38d0c3RET
>> I added an additional BenchmarkPopCountAlive benchmark.
>> 
>> var sum = 0 // Avoid dead code elimination.
>> 
>> func BenchmarkPopCountAlive(b *testing.B) {
>> sum = 0
>> 
>> for i := 0; i < b.N; i++ {
>> sum += PopCount(0x1234567890abcdef)
>> }
>> }
>> 
>> As you can see from the objdump, BenchmarkPopCountAlive code is not 
>> eliminated.
>> 
>> For details, see the popcount.txt attachment.
>> 
>> Peter
>> 
>> 
>> On Monday, May 31, 2021 at 6:29:27 PM UTC-4 Paul S. R. Chisholm wrote:
>>> This is not a serious problem, but it surprised me. (By the way, how can I 
>>> post a message with code formatting?)
>>> 
>>> I'd like to create table-driven benchmarks:
>>> https://blog.golang.org/subtests.
>>> 
>>> To that end, I started with code from *The Go Programming Language*:
>>> 
>>> // PopCount is based on an example from chapter 2 of THE GO PROGRAMMING 
>>> LANGUAGE.
>>> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
>>> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>>> 
>>> package popcount
>>> 
>>> // pc[i] is the population count of i.
>>> var pc [256]byte
>>> 
>>> func init() {
>>> for i := range pc {

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

There is no good reason that proper behavior should be dependent on 
understanding best practices. It should help with readability not correctness. 
Seems to me the compiler or Go Vet should prohibit this - in my review of the 
stdlib and other projects I can’t see any reason why it doesn’t. 

> On Jun 6, 2021, at 11:10 AM, jake...@gmail.com  wrote:
> 
> On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:
>> For example, the fact that this code is broken is not intuitively obvious 
>> for any reader. It requires way too much scrutiny IMO. 
>> 
>> https://play.golang.org/p/-f73t_Pm7ur
> 
> I would like to note that your example goes against the general advice that 
> all methods should be on either pointers or values. Mixing value and pointer 
> methods for the same types is a code smell. The code you posted is a good 
> example of one of the reasons why. 
> 
> The second to last paragraph in the FAQ section 
> https://golang.org/doc/faq#methods_on_values_or_pointers says:
> "If some of the methods of the type must have pointer receivers, the rest 
> should too, so the method set is consistent regardless of how the type is 
> used."
> 
> In your example, if MyEventRecorder.Log() is changed to have a pointer 
> receiver, then the code works as expected: 
> https://play.golang.org/p/MG10opC6Ect
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7C376006-EFA0-44BA-A036-B768078E4AA4%40ix.netcom.com.

Re: [go-nuts] Re: Ignore /vendor by default in polyglot repository

['Jacob Vosmaer' via golang-nuts]

On Fri, Jun 4, 2021 at 11:53 PM Amnon  wrote:
>
> How about renaming your vendor directory to something else?

That is not really an option because it is not "my" vendor directory.
For example, there is a lot of Ruby code in this repository, which
some people install with 'bundle install --deployment' which creates a
'/vendor/ruby' directory.

> On Friday, 4 June 2021 at 21:44:33 UTC+1 Brian Candler wrote:
>>
>> I don't suppose you could move all the go code down a level, say into a "go" 
>> subdirectory of the repo, including the go.mod file?

That is more or less the situation we're in now and I want to move
towards a top-level go.mod for the sake of automatic dependency
scanner tools (license detection, vulnerability scanners).

>> On Friday, 4 June 2021 at 17:44:37 UTC+1 manlio@gmail.com wrote:
>>>
>>> On Friday, June 4, 2021 at 6:24:28 PM UTC+2 Jacob Vosmaer wrote:

 What is possible already, now that I think about it, is for us to ask
 our contributors to run 'go env -w GOFLAGS=-mod=mod'. It's not
 something I would recommend in general because by the time you run
 into a problem because of that global value, you typically have
 forgotten you put it there.

>>>
>>> Have you thought about using a Makefile?  Or a make.bash/test.bash script?

We already have a Makefile for the Go code. That is fine for building
the software, but not great for development because the Go code I'm
talking about now has 34 packages and you don't always want to run 'go
test' for all 34 of them.

The moment you need fine grained control I think you need to use the
go tool chain.

If there was a local version of `go env`, as you suggested earlier,
then we could bootstrap that from our Makefile.

>>>
>>> One possible solution that is possible now is to set the go version in the 
>>> go.mod file to 1.13, so that the vendor directory is ignored:
>>> https://github.com/golang/go/blob/2e59cc5fb4/src/cmd/go/internal/modload/init.go#L699
>>>
>>> However it will prevent the use of recent features, like the embed package.

Thanks, that would indeed work, but it's not tenable in the long run
because someone will want to use new Go language features at some
point.

Too bad, it doesn't sound like there are any good options for me.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADMWQoOSxJRjcF7Aq1%2BcUx5_GSTgWvKhE_7oDhbps3JXRgSQqw%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

FWIW I do tend to mix value and pointer receivers occasionally.
Sometimes a type needs a pointer receiver in one method, but a different
method doesn't and it's more convenient to have a copy available for
temporary operations.
Usually when I implement flag.Var, I make `Set` use a pointer receiver and
`String` use a value receiver - because why not? There is no pointer needed
to stringify a value.
Sometimes I have a slice type which should generally be used and passed as
a value, but for convenience, I add a `push`/`pop` method to it, with a
pointer receiver.

Of course, all of these things *could* be accomplished by just using
pointer-receivers everywhere. But by that same logic, why have value
receivers anyway? You *could* always use a pointer.

I don't think it's a huge problem to mix the two. It's true that this means
the pointer and the value type implement different interfaces - but I don't
think that's a huge problem either. I *definitely* doubt that it's "the
most inconsistent and obtuse aspect of the Go language". I'm not saying it
*never* caused any problems for me, but it definitely isn't as frequent a
source of bugs as the behavior of closures in loops, or slices
unintentionally sharing elements after append… All of which I'm fine with
as well.

But FTR, this discussion is definitely off-topic in this thread. And it's
also moot in general: It's not something we can realistically change now.

On Mon, Jun 7, 2021 at 3:05 PM Robert Engels  wrote:

> 
> There is no good reason that proper behavior should be dependent on
> understanding best practices. It should help with readability not
> correctness. Seems to me the compiler or Go Vet should prohibit this - in
> my review of the stdlib and other projects I can’t see any reason why it
> doesn’t.
>
> On Jun 6, 2021, at 11:10 AM, jake...@gmail.com  wrote:
>
> 
> On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:
>
>> For example, the fact that this code is broken is not intuitively obvious
>> for any reader. It requires way too much scrutiny IMO.
>>
>> https://play.golang.org/p/-f73t_Pm7ur
>>
>
> I would like to note that your example goes against the general advice
> that all methods should be on either pointers or values. Mixing value and
> pointer methods for the same types is a code smell. The code you posted is
> a good example of one of the reasons why.
>
> The second to last paragraph in the FAQ section
> https://golang.org/doc/faq#methods_on_values_or_pointers says:
> "If some of the methods of the type must have pointer receivers, the rest
> should too, so the method set is consistent regardless of how the type is
> used."
>
> In your example, if MyEventRecorder.Log() is changed to have a pointer
> receiver, then the code works as expected:
> https://play.golang.org/p/MG10opC6Ect
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7C376006-EFA0-44BA-A036-B768078E4AA4%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGYRdadYFidvhCKnNqKDeqBSJLWBEU%3DuCJrxr1SbhPepQ%40mail.gmail.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

[Ross Light]

https://golang.org/issue/9859 is a proposal to support such syntax, but it 
hasn't really moved in a long time.

On Monday, June 7, 2021 at 2:47:07 AM UTC-7 axel.wa...@googlemail.com wrote:

> What we are saying is that you are misremembering. That's not how Go ever 
> worked.
>
> On Mon, Jun 7, 2021 at 11:36 AM Ally Dale  wrote:
>
>> As far as I remember(maybe I have missing something),  
>> var v = Value{
>> Name:"xxx",
>> }
>> Is the old way to initial an embeded field.
>> Some issuse changes the way of this.
>> I can't find the original discussion.
>>
>> 在2021年6月7日星期一 UTC+8 下午5:28:27 写道：
>>
>>> I don't understand the question. This has always been how the language 
>>> worked, all the way back to Go 1.0 at least. As far as I'm aware.
>>>
>>> Embedding only effects selector expressions and methods sets - i.e. it 
>>> allows you to write `v.Name` instead of writing `v.Base.Name`. It 
>>> doesn't affect composite literals.
>>>
>>> On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:
>>>
 Does anyone konw which proposal changes the access for embeded field 
 name of struct？
 Eg:
 ```
 type Base struct{
 Name string
 }
 type Value struct{
 Base
 }
 ```

 We initial a Value as:
 var v = Value{
 Base: Base{
 Name:"xxx",
 }
 }
 instead of 
 var v = Value{
 Name:"xxx",
 }

 I want to know why golang change the access method.
 Anyone who knows the isssue link, please reply me. Thanks a lot.

 -- 
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7d00093f-0253-489e-a5c9-40eceb5b2f1bn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dbe225d6-9c1e-4b5c-b3f0-34699d88f8e2n%40googlegroups.com.

[go-nuts] Surprising benchmark result

[tapi...@gmail.com]

The code: https://play.golang.org/p/DxUj6kBqf8k

The Filter4 function has one more assignment statement than Filter3.
But the benchmark result shows Filter4 is faster than Filter3.

The result:

cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
BenchmarkFilter3-43575656   980.2 ns/op   0 B/op
   0 allocs/op
BenchmarkFilter4-43956533   916.8 ns/op   0 B/op
   0 allocs/op


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4b6112d7-4781-4295-944b-f878abc1f67cn%40googlegroups.com.

Re: [go-nuts] Does anyone konw which proposal changes the access for embeded field name of struct?

[Ally Dale]

Thank a lot, this is the topic what I'm interested in.
Current syntax has troubled me in many cases.

在2021年6月7日星期一 UTC+8 下午10:35:47 写道：

> https://golang.org/issue/9859 is a proposal to support such syntax, but 
> it hasn't really moved in a long time.
>
> On Monday, June 7, 2021 at 2:47:07 AM UTC-7 axel.wa...@googlemail.com 
> wrote:
>
>> What we are saying is that you are misremembering. That's not how Go ever 
>> worked.
>>
>> On Mon, Jun 7, 2021 at 11:36 AM Ally Dale  wrote:
>>
>>> As far as I remember(maybe I have missing something),  
>>> var v = Value{
>>> Name:"xxx",
>>> }
>>> Is the old way to initial an embeded field.
>>> Some issuse changes the way of this.
>>> I can't find the original discussion.
>>>
>>> 在2021年6月7日星期一 UTC+8 下午5:28:27 写道：
>>>
 I don't understand the question. This has always been how the language 
 worked, all the way back to Go 1.0 at least. As far as I'm aware.

 Embedding only effects selector expressions and methods sets - i.e. it 
 allows you to write `v.Name` instead of writing `v.Base.Name`. It 
 doesn't affect composite literals.

 On Mon, Jun 7, 2021 at 11:20 AM Ally Dale  wrote:

> Does anyone konw which proposal changes the access for embeded field 
> name of struct？
> Eg:
> ```
> type Base struct{
> Name string
> }
> type Value struct{
> Base
> }
> ```
>
> We initial a Value as:
> var v = Value{
> Base: Base{
> Name:"xxx",
> }
> }
> instead of 
> var v = Value{
> Name:"xxx",
> }
>
> I want to know why golang change the access method.
> Anyone who knows the isssue link, please reply me. Thanks a lot.
>
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ff4f3443-c863-4d96-958c-76023979b0ben%40googlegroups.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...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/7d00093f-0253-489e-a5c9-40eceb5b2f1bn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1b304e53-e78e-4ac5-ae70-7feb3e523141n%40googlegroups.com.

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[peterGo]

Ian,

I don't know whether it is feasible. It is unnecessary.

A benchmark should be treated as a scientific experiment. If we do that 
with Paul's benchmarks and write them in scientific form, then we get the 
expected results.

$ benchstat xpt.txt
name  time/op
PopCountSimple-4  5.71ns ± 0%
PopCountSlowSimple-4  5.70ms ± 0%
PopCountAlmostSimple/BenchmarkPopCountAlmostSimple-4  5.70ns ± 0%
PopCountNearlySimple/PopCountNearlySimple-4   5.69ns ± 0%
$

Peter


On Monday, June 7, 2021 at 6:14:05 AM UTC-4 Ian Davis wrote:

> Would it be feasible for the Go tool to disable inlining and deadcode 
> elimination of code within the bodies of Benchmarks and Tests? Not the code 
> under test of course. It could be as crude as disabling these optimizations 
> for files in _test.go files.
>
>
>
> On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
>
> Thanks! I'd seen the "dead code elimination" comment somewhere and 
> questioned it, but not enough.
>
> If I worry about what some future Go compiler might optimize, I end up 
> worrying quite a lot! For example, could this code:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> hypothetically be optimized to:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = PopCount(0x1234567890abcdef) * b.N
> }
>
> since PopCount() always returns the same value for the same argument? It 
> probably wouldn't, since that would break many existing benchmarks.
>
> Maybe more reasonably worrisome: If sum is initialized and incremented but 
> never read, could all references to it be optimized away? That's easy 
> enough to avoid, as is the optimization I worried about above:
>
> var sum = 0 // Avoid dead code elimination
> const firstInput uint64 = 0x1234567890abcdef
>
> func BenchmarkPopCountSimple(b *testing.B) {
> for i, input := 0, firstInput; i < b.N; i++ {
> sum += PopCount(input)
> input++
> }
> if sum == 0 {
> b.Error("BenchmarkPopCountSimple: sum == 0")
> }
> }
>
> Here are my new benchmark results:
>
> $ go version
> go version go1.16.5 windows/amd64
> $ go test -cpu=1 -bench=.
> goos: windows
> goarch: amd64
> pkg: gopl.io/popcount
> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
> BenchmarkPopCountSimple 2710047904.419 ns/op
> BenchmarkPopCountSlowSimple  278   4235890 ns/op
> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
> 2727591344.434 ns/op
> BenchmarkPopCountNearlySimple/PopCountNearlySimple 
>  1456130778.172 ns/op
> PASS
> ok  gopl.io/popcount7.061s
>
> The anomalistically-low "simple" and "almost simple" results are now more 
> reasonable, but still nearly a factor of two lower than the "nearly simple" 
> results. They're still inlining the calls, as is the "slow simple" 
> benchmark, where the "nearly simple" one isn't:
>
> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to 
> PopCount'
> .\popcount_test.go:10:18: inlining call to PopCount
> .\popcount_test.go:22:19: inlining call to PopCount
> .\popcount_test.go:34:19: inlining call to PopCount
>
> Overkill, right? --PSRC
>
> P.S.: For better or worse, I discovered I can -- but shouldn't, based on 
> the feedback I got! -- get "fancy" formatting by copying from vscode and 
> pasting into Gmail.
>
>
>
> On Tuesday, June 1, 2021 at 12:01:51 PM UTC-4 peterGo wrote:
>
> Here is a more definitive reply than my original reply.
>
>
> I got as far as this
> func BenchmarkPopCountSimple(b *testing.B) {
> sum := 0 // Avoid dead code elimination.
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> As you can see from the objdump, BenchmarkPopCountSimple dead code is 
> eliminated.
>
> func BenchmarkPopCountSimple(b *testing.B) {
>   0x4e38c031c9XORL CX, CX
>
> for i := 0; i < b.N; i++ {
>   0x4e38c2eb03JMP 0x4e38c7
>   0x4e38c448ffc1INCQ CX
>   0x4e38c74839889001CMPQ CX, 0x190(AX)
>   0x4e38ce7ff4JG 0x4e38c4
> }
>   0x4e38d0c3RET
> I added an additional BenchmarkPopCountAlive benchmark.
>
> var sum = 0 // Avoid dead code elimination.
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
>
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> As you can see from the objdump, BenchmarkPopCountAlive code is not 
> eliminated.
>
> For details, see the popcount.txt attachment.
>
> Peter
>
>
> On Monday, May 31, 2021 at 6:29:27 PM UTC-4 Paul S. R. Chisholm wrote:
>
> This is not a serious problem, but it surprised me. (By the way, ho

[go-nuts] Re: Surprising benchmark result

[jake...@gmail.com]

FWIW I do not get the same result:

goos: windows
goarch: amd64
cpu: AMD Phenom(tm) II X4 830 Processor
BenchmarkFilter3-4599912  1902 ns/op   0 
B/op  0 allocs/op
BenchmarkFilter4-4569143  2118 ns/op   0 
B/op  0 allocs/op
PASS

On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:

>
> The code: https://play.golang.org/p/DxUj6kBqf8k
>
> The Filter4 function has one more assignment statement than Filter3.
> But the benchmark result shows Filter4 is faster than Filter3.
>
> The result:
>
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> BenchmarkFilter3-43575656   980.2 ns/op   0 
> B/op   0 allocs/op
> BenchmarkFilter4-43956533   916.8 ns/op   0 
> B/op   0 allocs/op
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18a41a4e-a648-4777-a906-e024a8ee4838n%40googlegroups.com.

Re: [go-nuts] Re: Table-driven benchmarks defeat inlining

[Ian Davis]

Go does a good job of making it easy to do the right thing, especially in tests 
(such as parallel benchmarks or setting env variables), and avoiding the need 
for tricks like package level variables or noinline directives seems a useful 
feature.

On Mon, 7 Jun 2021, at 4:47 PM, peterGo wrote:
> Ian,
> 
> I don't know whether it is feasible. It is unnecessary.
> 
> A benchmark should be treated as a scientific experiment. If we do that with 
> Paul's benchmarks and write them in scientific form, then we get the expected 
> results.
> 
> $ benchstat xpt.txt
> name  time/op
> PopCountSimple-4  5.71ns ± 0%
> PopCountSlowSimple-4  5.70ms ± 0%
> PopCountAlmostSimple/BenchmarkPopCountAlmostSimple-4  5.70ns ± 0%
> PopCountNearlySimple/PopCountNearlySimple-4   5.69ns ± 0%
> $
> 
> Peter
> 
> 
> On Monday, June 7, 2021 at 6:14:05 AM UTC-4 Ian Davis wrote:
>> __
>> Would it be feasible for the Go tool to disable inlining and deadcode 
>> elimination of code within the bodies of Benchmarks and Tests? Not the code 
>> under test of course. It could be as crude as disabling these optimizations 
>> for files in _test.go files.
>> 
>> 
>> 
>> On Sun, 6 Jun 2021, at 1:33 PM, Paul S. R. Chisholm wrote:
>>> Thanks! I'd seen the "dead code elimination" comment somewhere and 
>>> questioned it, but not enough.
>>> 
>>> If I worry about what some future Go compiler might optimize, I end up 
>>> worrying quite a lot! For example, could this code:
>>> 
>>> func BenchmarkPopCountAlive(b *testing.B) {
>>> sum = 0
>>> for i := 0; i < b.N; i++ {
>>> sum += PopCount(0x1234567890abcdef)
>>> }
>>> }
>>> 
>>> hypothetically be optimized to:
>>> 
>>> func BenchmarkPopCountAlive(b *testing.B) {
>>> sum = PopCount(0x1234567890abcdef) * b.N
>>> }
>>> 
>>> since PopCount() always returns the same value for the same argument? It 
>>> probably wouldn't, since that would break many existing benchmarks.
>>> 
>>> Maybe more reasonably worrisome: If sum is initialized and incremented but 
>>> never read, could all references to it be optimized away? That's easy 
>>> enough to avoid, as is the optimization I worried about above:
>>> 
>>> var sum = 0 // Avoid dead code elimination
>>> const firstInput uint64 = 0x1234567890abcdef
>>> 
>>> func BenchmarkPopCountSimple(b *testing.B) {
>>> for i, input := 0, firstInput; i < b.N; i++ {
>>> sum += PopCount(input)
>>> input++
>>> }
>>> if sum == 0 {
>>> b.Error("BenchmarkPopCountSimple: sum == 0")
>>> }
>>> }
>>> 
>>> Here are my new benchmark results:
>>> 
>>> $ go version
>>> go version go1.16.5 windows/amd64
>>> $ go test -cpu=1 -bench=.
>>> goos: windows
>>> goarch: amd64
>>> pkg: gopl.io/popcount
>>> cpu: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
>>> BenchmarkPopCountSimple 2710047904.419 ns/op
>>> BenchmarkPopCountSlowSimple  278   4235890 ns/op
>>> BenchmarkPopCountAlmostSimple/BenchmarkPopCountAlmostSimple 
>>> 2727591344.434 ns/op
>>> BenchmarkPopCountNearlySimple/PopCountNearlySimple  
>>> 1456130778.172 ns/op
>>> PASS
>>> ok  gopl.io/popcount7.061s
>>> 
>>> The anomalistically-low "simple" and "almost simple" results are now more 
>>> reasonable, but still nearly a factor of two lower than the "nearly simple" 
>>> results. They're still inlining the calls, as is the "slow simple" 
>>> benchmark, where the "nearly simple" one isn't:
>>> 
>>> $ go test -cpu=1 -bench=. -gcflags=-m 2>&1 | egrep 'inlining call to 
>>> PopCount'
>>> .\popcount_test.go:10:18: inlining call to PopCount
>>> .\popcount_test.go:22:19: inlining call to PopCount
>>> .\popcount_test.go:34:19: inlining call to PopCount
>>> 
>>> Overkill, right? --PSRC
>>> 
>>> P.S.: For better or worse, I discovered I can -- but shouldn't, based on 
>>> the feedback I got! -- get "fancy" formatting by copying from vscode and 
>>> pasting into Gmail.
>>> 
>>> 
>>> 
>>> On Tuesday, June 1, 2021 at 12:01:51 PM UTC-4 peterGo wrote:
 Here is a more definitive reply than my original reply.
 
 
 I got as far as this
 func BenchmarkPopCountSimple(b *testing.B) {
 sum := 0 // Avoid dead code elimination.
 for i := 0; i < b.N; i++ {
 sum += PopCount(0x1234567890abcdef)
 }
 }
 
 As you can see from the objdump, BenchmarkPopCountSimple dead code is 
 eliminated.
 
 func BenchmarkPopCountSimple(b *testing.B) {
   0x4e38c031c9XORL CX, CX
 
 for i := 0; i < b.N; i++ {
   0x4e38c2eb03JMP 0x4e38c7
   0x4e38c448ffc1INCQ CX
   0x4e38c74839889001CMPQ CX, 0x190(AX)
   0x4e38ce7ff4JG 0x4e38c4
 }
   0x4e38

[go-nuts] wanted to know about telco grade open source orchestration project

['NM Trivedi' via golang-nuts]

Hi all, I want to know are there any telco grade open source policy frame 
work orchestration projects based on the golang.

If anyone has got information on this, please share with me.

Thanks and Regards

N.M.Trivedi

-- 
*STL - Sterlite Technologies Limited Disclaimer:*
The content of this 
message may be legally privileged and confidential and are for the use of 
the intended recipient(s) only. It should not be read, copied and used by 
anyone other than the intended recipient(s). If you have received this 
message in error, please immediately notify the sender, preserve its 
confidentiality and delete it. Before opening any attachments please check 
them for viruses and defects. No employee or agent is authorised to 
conclude any binding agreement on behalf of Sterlite Technologies Limited 
with another party by email without express written confirmation by 
authorised person. Visit us at www.stl.tech 
 
Please consider environment before printing this email !


Registered 
office: E 1, MIDC Industrial Area, Waluj,
Aurangabad, Maharashtra – 431 136 
CIN – L31300MH2000PLC269261

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/642a1472-549e-429c-a845-0b970ed06d0dn%40googlegroups.com.

[go-nuts] Newbie: Where I can get to see Go routines' white paper and its implementation ( Header file equivalent) in Go Repo'?

[FallingFromBed]

Newbie: Where I can get to see Go routines' white paper and its 
implementation ( Header file equivalent) in Go Repo'? 

Thanks,
 FFB

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c2d04efa-20e9-4c41-8e17-aab08252973an%40googlegroups.com.

[go-nuts] How to know if a symbol extracted from symbol table is DSO load or elf symbol?

[Iti Shree]

Hello everyone,

I am trying to understand  *debug/elf* package especially method *Symbols()* 
. I was wondering if there's any way to determine whether symbol name or 
address of symbol is closest to elf symbol or DSO load address. I am 
relatively new to the package so sorry for any silly questions.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57554529-9634-4c39-b014-f04c0dae4337n%40googlegroups.com.

[go-nuts] Re: Surprising benchmark result

[peterGo]

name   time/op
Filter3-4  1.38µs ± 0%
Filter4-4  1.39µs ± 0%


On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:

>
> The code: https://play.golang.org/p/DxUj6kBqf8k
>
> The Filter4 function has one more assignment statement than Filter3.
> But the benchmark result shows Filter4 is faster than Filter3.
>
> The result:
>
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> BenchmarkFilter3-43575656   980.2 ns/op   0 
> B/op   0 allocs/op
> BenchmarkFilter4-43956533   916.8 ns/op   0 
> B/op   0 allocs/op
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39f6f3f0-08bf-431a-9f02-650ad0f03d3fn%40googlegroups.com.

Re: [go-nuts] Newbie: Where I can get to see Go routines' white paper and its implementation ( Header file equivalent) in Go Repo'?

[Ian Lance Taylor]

On Mon, Jun 7, 2021 at 9:16 AM FallingFromBed  wrote:
>
> Newbie: Where I can get to see Go routines' white paper and its 
> implementation ( Header file equivalent) in Go Repo'?

I'm not sure what you mean by a white paper, but I doubt that it
exists.  Also, Go does not have header files or anything equivalent to
them.

The implementation of goroutines is spread across a number of
different areas.  The central point is the scheduler, which is mostly
in https://golang.org/src/runtime/proc.go.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXiyTxAjAP%3DWOj2etWvE6fhuXuFYPx2V4A1fWJi63mPxA%40mail.gmail.com.

Re: [go-nuts] How to know if a symbol extracted from symbol table is DSO load or elf symbol?

[Ian Lance Taylor]

On Mon, Jun 7, 2021 at 9:16 AM Iti Shree  wrote:
>
> I am trying to understand  debug/elf package especially method Symbols() . I 
> was wondering if there's any way to determine whether symbol name or address 
> of symbol is closest to elf symbol or DSO load address. I am relatively new 
> to the package so sorry for any silly questions.

The debug/elf Symbol structure is the ELF symbol, the same information
you see from "nm" or "readelf -s".

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU9ucK6qgUE-2BCqCTz5fpoS1ZFjxSXw2w-qTvk7DxvYA%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

I think that is my point. The methods in the code I shared have a proper 
receiver type based on the requirements of the methods. It only “breaks” in the 
context of the usage which isn’t at all obvious. 

So it seems to me that go lint should at least complain that a struct has 
mutating methods so all methods should take pointer receivers. 

> On Jun 7, 2021, at 9:19 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
> FWIW I do tend to mix value and pointer receivers occasionally.
> Sometimes a type needs a pointer receiver in one method, but a different 
> method doesn't and it's more convenient to have a copy available for 
> temporary operations.
> Usually when I implement flag.Var, I make `Set` use a pointer receiver and 
> `String` use a value receiver - because why not? There is no pointer needed 
> to stringify a value.
> Sometimes I have a slice type which should generally be used and passed as a 
> value, but for convenience, I add a `push`/`pop` method to it, with a pointer 
> receiver.
> 
> Of course, all of these things *could* be accomplished by just using 
> pointer-receivers everywhere. But by that same logic, why have value 
> receivers anyway? You *could* always use a pointer.
> 
> I don't think it's a huge problem to mix the two. It's true that this means 
> the pointer and the value type implement different interfaces - but I don't 
> think that's a huge problem either. I *definitely* doubt that it's "the most 
> inconsistent and obtuse aspect of the Go language". I'm not saying it *never* 
> caused any problems for me, but it definitely isn't as frequent a source of 
> bugs as the behavior of closures in loops, or slices unintentionally sharing 
> elements after append… All of which I'm fine with as well.
> 
> But FTR, this discussion is definitely off-topic in this thread. And it's 
> also moot in general: It's not something we can realistically change now.
> 
>> On Mon, Jun 7, 2021 at 3:05 PM Robert Engels  wrote:
>> 
>> There is no good reason that proper behavior should be dependent on 
>> understanding best practices. It should help with readability not 
>> correctness. Seems to me the compiler or Go Vet should prohibit this - in my 
>> review of the stdlib and other projects I can’t see any reason why it 
>> doesn’t. 
>> 
 On Jun 6, 2021, at 11:10 AM, jake...@gmail.com  wrote:
 
>>> 
 On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:
 For example, the fact that this code is broken is not intuitively obvious 
 for any reader. It requires way too much scrutiny IMO. 
 
 https://play.golang.org/p/-f73t_Pm7ur 
>>> 
>>> I would like to note that your example goes against the general advice that 
>>> all methods should be on either pointers or values. Mixing value and 
>>> pointer methods for the same types is a code smell. The code you posted is 
>>> a good example of one of the reasons why. 
>>> 
>>> The second to last paragraph in the FAQ section 
>>> https://golang.org/doc/faq#methods_on_values_or_pointers says:
>>> "If some of the methods of the type must have pointer receivers, the rest 
>>> should too, so the method set is consistent regardless of how the type is 
>>> used."
>>> 
>>> In your example, if MyEventRecorder.Log() is changed to have a pointer 
>>> receiver, then the code works as expected: 
>>> https://play.golang.org/p/MG10opC6Ect
>>> 
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7C376006-EFA0-44BA-A036-B768078E4AA4%40ix.netcom.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGYRdadYFidvhCKnNqKDeqBSJLWBEU%3DuCJrxr1SbhPepQ%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/406A98CC-3D33-44A0-80E0-E40448DA3721%40ix.netcom.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Mon, Jun 7, 2021 at 7:42 PM Robert Engels  wrote:

> I think that is my point. The methods in the code I shared have a proper
> receiver type based on the requirements of the methods.
>

No, they don't. The `Log` method requires a pointer receiver, as it
accesses state that is supposed to be shared. Once you fix that, the
compiler will quite correct complain that the value does not implement the
interface in question.

Note that the code behaves the same even if no interfaces are involved:
https://play.golang.org/p/WpIzYYLOKn-

So it seems to me that go lint should at least complain that a struct has
> mutating methods so all methods should take pointer receivers.
>

I disagree.


>
>
> On Jun 7, 2021, at 9:19 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> FWIW I do tend to mix value and pointer receivers occasionally.
> Sometimes a type needs a pointer receiver in one method, but a different
> method doesn't and it's more convenient to have a copy available for
> temporary operations.
> Usually when I implement flag.Var, I make `Set` use a pointer receiver and
> `String` use a value receiver - because why not? There is no pointer needed
> to stringify a value.
> Sometimes I have a slice type which should generally be used and passed as
> a value, but for convenience, I add a `push`/`pop` method to it, with a
> pointer receiver.
>
> Of course, all of these things *could* be accomplished by just using
> pointer-receivers everywhere. But by that same logic, why have value
> receivers anyway? You *could* always use a pointer.
>
> I don't think it's a huge problem to mix the two. It's true that this
> means the pointer and the value type implement different interfaces - but I
> don't think that's a huge problem either. I *definitely* doubt that it's
> "the most inconsistent and obtuse aspect of the Go language". I'm not
> saying it *never* caused any problems for me, but it definitely isn't as
> frequent a source of bugs as the behavior of closures in loops, or slices
> unintentionally sharing elements after append… All of which I'm fine with
> as well.
>
> But FTR, this discussion is definitely off-topic in this thread. And it's
> also moot in general: It's not something we can realistically change now.
>
> On Mon, Jun 7, 2021 at 3:05 PM Robert Engels 
> wrote:
>
>> 
>> There is no good reason that proper behavior should be dependent on
>> understanding best practices. It should help with readability not
>> correctness. Seems to me the compiler or Go Vet should prohibit this - in
>> my review of the stdlib and other projects I can’t see any reason why it
>> doesn’t.
>>
>> On Jun 6, 2021, at 11:10 AM, jake...@gmail.com 
>> wrote:
>>
>> 
>> On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:
>>
>>> For example, the fact that this code is broken is not intuitively
>>> obvious for any reader. It requires way too much scrutiny IMO.
>>>
>>> https://play.golang.org/p/-f73t_Pm7ur
>>>
>>
>> I would like to note that your example goes against the general advice
>> that all methods should be on either pointers or values. Mixing value and
>> pointer methods for the same types is a code smell. The code you posted is
>> a good example of one of the reasons why.
>>
>> The second to last paragraph in the FAQ section
>> https://golang.org/doc/faq#methods_on_values_or_pointers says:
>> "If some of the methods of the type must have pointer receivers, the rest
>> should too, so the method set is consistent regardless of how the type is
>> used."
>>
>> In your example, if MyEventRecorder.Log() is changed to have a pointer
>> receiver, then the code works as expected:
>> https://play.golang.org/p/MG10opC6Ect
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7C376006-EFA0-44BA-A036-B768078E4AA4%40ix.netcom.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...

Re: [go-nuts] Newbie: Where I can get to see Go routines' white paper and its implementation ( Header file equivalent) in Go Repo'?

[Artur Vianna]

Not a white paper per se, but there are a few resources by Dmitry Vyukov
that i came about:

A Talk: https://youtu.be/-K11rY57K7k

The Slides:
https://assets.ctfassets.net/oxjq45e8ilak/48lwQdnyDJr2O64KUsUB5V/5d8343da0119045c4b26eb65a83e786f/100545_516729073_DMITRII_VIUKOV_Go_scheduler_Implementing_language_with_lightweight_concurrency.pdf

There's also this design doc:
https://docs.google.com/document/u/0/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/mobilebasic

Hope it helps!



On Mon, 7 Jun 2021, 13:16 FallingFromBed,  wrote:

>
> Newbie: Where I can get to see Go routines' white paper and its
> implementation ( Header file equivalent) in Go Repo'?
>
> Thanks,
>  FFB
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c2d04efa-20e9-4c41-8e17-aab08252973an%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAE%3DAWBXwrV%2B5gLnCUBzvnDL_CMy9EUZz-g8PKRq1%3DHoEPtOzBg%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [210607 10:19]:
> FWIW I do tend to mix value and pointer receivers occasionally.
> Sometimes a type needs a pointer receiver in one method, but a different
> method doesn't and it's more convenient to have a copy available for
> temporary operations.

Axel, I believe you already understand this, but for others following
along who want to understand when it might be appropriate to do this, I
would like to point out that for a type T with method Foo that has a
value receiver and method Goo that has a pointer receiver, and interface
I with methods matching Foo and Goo, T does not satisfy I, but *T does.
This is just something to keep in mind when weighing the possibilities.

...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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210607184622.x6fqx3f5i6et4jbn%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

I don’t think that represents the problem fairly. In the non interface case I 
know I can’t accept a copy so I would declare the method as taking a pointer to 
the struct. 

With interfaces this is lost - as the interface is implicitly a pointer - but 
whether it points to a copy or the original is unknown because the dev writing 
the interface declaration and function using the interface only knows they need 
something with a Log().  

It is the implicit copying for the interface which makes it obtuse. 

> On Jun 7, 2021, at 12:57 PM, Axel Wagner  
> wrote:
> 
> 
>> On Mon, Jun 7, 2021 at 7:42 PM Robert Engels  wrote:
> 
>> I think that is my point. The methods in the code I shared have a proper 
>> receiver type based on the requirements of the methods.
> 
> No, they don't. The `Log` method requires a pointer receiver, as it accesses 
> state that is supposed to be shared. Once you fix that, the compiler will 
> quite correct complain that the value does not implement the interface in 
> question.
> 
> Note that the code behaves the same even if no interfaces are involved: 
> https://play.golang.org/p/WpIzYYLOKn-
> 
>> So it seems to me that go lint should at least complain that a struct has 
>> mutating methods so all methods should take pointer receivers.
> 
> I disagree.
>  
>>  
>> 
 On Jun 7, 2021, at 9:19 AM, 'Axel Wagner' via golang-nuts 
  wrote:
 
>>> 
>>> FWIW I do tend to mix value and pointer receivers occasionally.
>>> Sometimes a type needs a pointer receiver in one method, but a different 
>>> method doesn't and it's more convenient to have a copy available for 
>>> temporary operations.
>>> Usually when I implement flag.Var, I make `Set` use a pointer receiver and 
>>> `String` use a value receiver - because why not? There is no pointer needed 
>>> to stringify a value.
>>> Sometimes I have a slice type which should generally be used and passed as 
>>> a value, but for convenience, I add a `push`/`pop` method to it, with a 
>>> pointer receiver.
>>> 
>>> Of course, all of these things *could* be accomplished by just using 
>>> pointer-receivers everywhere. But by that same logic, why have value 
>>> receivers anyway? You *could* always use a pointer.
>>> 
>>> I don't think it's a huge problem to mix the two. It's true that this means 
>>> the pointer and the value type implement different interfaces - but I don't 
>>> think that's a huge problem either. I *definitely* doubt that it's "the 
>>> most inconsistent and obtuse aspect of the Go language". I'm not saying it 
>>> *never* caused any problems for me, but it definitely isn't as frequent a 
>>> source of bugs as the behavior of closures in loops, or slices 
>>> unintentionally sharing elements after append… All of which I'm fine with 
>>> as well.
>>> 
>>> But FTR, this discussion is definitely off-topic in this thread. And it's 
>>> also moot in general: It's not something we can realistically change now.
>>> 
 On Mon, Jun 7, 2021 at 3:05 PM Robert Engels  wrote:
 
 There is no good reason that proper behavior should be dependent on 
 understanding best practices. It should help with readability not 
 correctness. Seems to me the compiler or Go Vet should prohibit this - in 
 my review of the stdlib and other projects I can’t see any reason why it 
 doesn’t. 
 
>> On Jun 6, 2021, at 11:10 AM, jake...@gmail.com  
>> wrote:
>> 
> 
>> On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:
>> For example, the fact that this code is broken is not intuitively 
>> obvious for any reader. It requires way too much scrutiny IMO. 
>> 
>> https://play.golang.org/p/-f73t_Pm7ur 
> 
> I would like to note that your example goes against the general advice 
> that all methods should be on either pointers or values. Mixing value and 
> pointer methods for the same types is a code smell. The code you posted 
> is a good example of one of the reasons why. 
> 
> The second to last paragraph in the FAQ section 
> https://golang.org/doc/faq#methods_on_values_or_pointers says:
> "If some of the methods of the type must have pointer receivers, the rest 
> should too, so the method set is consistent regardless of how the type is 
> used."
> 
> In your example, if MyEventRecorder.Log() is changed to have a pointer 
> receiver, then the code works as expected: 
> https://play.golang.org/p/MG10opC6Ect
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.com.
 
 -- 
 You received this message because you are subscribed to the Google Gro

Re: [go-nuts] times of stw in one gc cycle?

[Ian Lance Taylor]

On Sun, Jun 6, 2021 at 4:19 AM xie cui  wrote:
>
> https://github.com/golang/go/blob/master/src/runtime/mgc.go#L858-L876
> due to these code lines, stw in one gc cycle may happen more than 2 times. so 
> stw times  in one gc cycle could be 2(general), 3, 4,  and even for ever?

Theoretically, yes.  In practice, this is not a problem.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU_R7G5b7t7jEcw3Z2u%3D5_tm1XECBwV6OXzeam-KO%3D3%2BA%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Mon, Jun 7, 2021 at 11:42 PM Robert Engels  wrote:

> I don’t think that represents the problem fairly. In the non interface
> case I know I can’t accept a copy so I would declare the method as taking a
> pointer to the struct.
>

How methods are declared should, in general, not be a matter of whether or
not they are assigned to an interface, but to whether or not they need a
pointer. Again: Your code is incorrect without interfaces
. The problem doesn't happen when
you put that value into an interface - it happens when you pass a copy of
it and expect it to refer to the original. Interfaces are just one way to
create such a copy, but they do not matter for the correctness of this code
and for whether or not that method needs a pointer receiver (it does).

But again, to be clear: I'm not saying problems like this *never* happen
and I'm not even saying that interfaces may obscure it in some cases. Just
that a) the root cause here is that your method really needs to take a
pointer-receiver, interfaces or not and b) that it seems very much an
overstatement to me to call this "the most inconsistent and obtuse aspect
of the Go language".

With interfaces this is lost - as the interface is implicitly a pointer
>

Well, it seems a bad idea to say that interfaces are implicitly pointers
then. That seems to indicate that Rob's original phrasing is indeed an
important clarification - the language behaves as if the value contained in
them is copied when the interface value is copied.

It seems the confusion here is, that you assume it's not. And that
interfaces act as a pointers, when they don't.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFBaCPtfm9CczQT8uAEXVypAO0tteCUQQQ%2BZKWFv7Gy%3DA%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

BTW, just to nail down the point of that code being wrong without
interfaces: Your usage of `atomic` in `Log` is superfluous. You are
operating on a local variable, so there is no possibility of concurrent
modification. Your code is equivalent to this:
https://play.golang.org/p/zYG0zTsk-2a
The only reason to use `atomic` here (and why you used it) is if that
memory could be shared between goroutines. For that to happen, you need a
pointer receiver though.

I refuse to believe that interfaces have anything to do with this
obfuscation here. There is more than enough indication of it being wrong in
any case.

On Tue, Jun 8, 2021 at 1:05 AM Axel Wagner 
wrote:

> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels 
> wrote:
>
>> I don’t think that represents the problem fairly. In the non interface
>> case I know I can’t accept a copy so I would declare the method as taking a
>> pointer to the struct.
>>
>
> How methods are declared should, in general, not be a matter of whether or
> not they are assigned to an interface, but to whether or not they need a
> pointer. Again: Your code is incorrect without interfaces
> . The problem doesn't happen when
> you put that value into an interface - it happens when you pass a copy of
> it and expect it to refer to the original. Interfaces are just one way to
> create such a copy, but they do not matter for the correctness of this code
> and for whether or not that method needs a pointer receiver (it does).
>
> But again, to be clear: I'm not saying problems like this *never* happen
> and I'm not even saying that interfaces may obscure it in some cases. Just
> that a) the root cause here is that your method really needs to take a
> pointer-receiver, interfaces or not and b) that it seems very much an
> overstatement to me to call this "the most inconsistent and obtuse aspect
> of the Go language".
>
> With interfaces this is lost - as the interface is implicitly a pointer
>>
>
> Well, it seems a bad idea to say that interfaces are implicitly pointers
> then. That seems to indicate that Rob's original phrasing is indeed an
> important clarification - the language behaves as if the value contained in
> them is copied when the interface value is copied.
>
> It seems the confusion here is, that you assume it's not. And that
> interfaces act as a pointers, when they don't.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGVyvYYpQhCp_JkxN9EvgZ4FXJ8_WpxseJOB1OR7qt6ww%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

I think that is why it is inconsistent and obtuse to me.  The Log() method 
doesn’t need a pointer receiver. It works fine without it. It only needs a 
pointer receiver because when passed to a function declared as taking an 
interface a copy is made (and a reference to the copy held). This copy is 
implicit not explicit. This is a difficult model when working on large multi 
person projects - thus the “best practice” of using only pointer or value 
receivers I think. Suggesting that the linter flags code not adhering to this 
seems to have very little downside if any. 

A quick search on the web (and the faq language) makes me think I am not alone 
in this opinion.

I guess I still don’t see the downside to linter changes. As I said I reviewed 
a lot of the stdlib and I don’t see any obvious mixed receiver structs. They 
can be disabled on a per struct basis if needed. 

Anyway it was just my opinion based on my experiences. 

> On Jun 7, 2021, at 6:05 PM, Axel Wagner  wrote:
> 
> 
>> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels  wrote:
> 
>> I don’t think that represents the problem fairly. In the non interface case 
>> I know I can’t accept a copy so I would declare the method as taking a 
>> pointer to the struct.
> 
> How methods are declared should, in general, not be a matter of whether or 
> not they are assigned to an interface, but to whether or not they need a 
> pointer. Again: Your code is incorrect without interfaces. The problem 
> doesn't happen when you put that value into an interface - it happens when 
> you pass a copy of it and expect it to refer to the original. Interfaces are 
> just one way to create such a copy, but they do not matter for the 
> correctness of this code and for whether or not that method needs a pointer 
> receiver (it does).
> 
> But again, to be clear: I'm not saying problems like this *never* happen and 
> I'm not even saying that interfaces may obscure it in some cases. Just that 
> a) the root cause here is that your method really needs to take a 
> pointer-receiver, interfaces or not and b) that it seems very much an 
> overstatement to me to call this "the most inconsistent and obtuse aspect of 
> the Go language".
> 
>> With interfaces this is lost - as the interface is implicitly a pointer
> 
> Well, it seems a bad idea to say that interfaces are implicitly pointers 
> then. That seems to indicate that Rob's original phrasing is indeed an 
> important clarification - the language behaves as if the value contained in 
> them is copied when the interface value is copied.
> 
> It seems the confusion here is, that you assume it's not. And that interfaces 
> act as a pointers, when they don't.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F93E0A12-F3D2-4AAE-8D3E-091DF4A8AE60%40ix.netcom.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

The pattern of a background stats collector is a common one. The atomic is 
required not optional. 

> On Jun 7, 2021, at 6:16 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
> BTW, just to nail down the point of that code being wrong without interfaces: 
> Your usage of `atomic` in `Log` is superfluous. You are operating on a local 
> variable, so there is no possibility of concurrent modification. Your code is 
> equivalent to this: https://play.golang.org/p/zYG0zTsk-2a
> The only reason to use `atomic` here (and why you used it) is if that memory 
> could be shared between goroutines. For that to happen, you need a pointer 
> receiver though.
> 
> I refuse to believe that interfaces have anything to do with this obfuscation 
> here. There is more than enough indication of it being wrong in any case.
> 
>> On Tue, Jun 8, 2021 at 1:05 AM Axel Wagner  
>> wrote:
>>> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels  wrote:
>> 
>>> I don’t think that represents the problem fairly. In the non interface case 
>>> I know I can’t accept a copy so I would declare the method as taking a 
>>> pointer to the struct.
>> 
>> How methods are declared should, in general, not be a matter of whether or 
>> not they are assigned to an interface, but to whether or not they need a 
>> pointer. Again: Your code is incorrect without interfaces. The problem 
>> doesn't happen when you put that value into an interface - it happens when 
>> you pass a copy of it and expect it to refer to the original. Interfaces are 
>> just one way to create such a copy, but they do not matter for the 
>> correctness of this code and for whether or not that method needs a pointer 
>> receiver (it does).
>> 
>> But again, to be clear: I'm not saying problems like this *never* happen and 
>> I'm not even saying that interfaces may obscure it in some cases. Just that 
>> a) the root cause here is that your method really needs to take a 
>> pointer-receiver, interfaces or not and b) that it seems very much an 
>> overstatement to me to call this "the most inconsistent and obtuse aspect of 
>> the Go language".
>> 
>>> With interfaces this is lost - as the interface is implicitly a pointer
>> 
>> Well, it seems a bad idea to say that interfaces are implicitly pointers 
>> then. That seems to indicate that Rob's original phrasing is indeed an 
>> important clarification - the language behaves as if the value contained in 
>> them is copied when the interface value is copied.
>> 
>> It seems the confusion here is, that you assume it's not. And that 
>> interfaces act as a pointers, when they don't.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGVyvYYpQhCp_JkxN9EvgZ4FXJ8_WpxseJOB1OR7qt6ww%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/DC6B566F-9D93-4EE2-BFD9-4CF797298EFD%40ix.netcom.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 1:25 AM Robert Engels  wrote:

> I think that is why it is inconsistent and obtuse to me.  The Log() method
> doesn’t need a pointer receiver. It works fine without it.
>

I don't understand how you can continue to say that. I've linked the code
several times. It does not work. Or, if it does work, it also works with
interfaces. The behavior is the same in both cases.


> It only needs a pointer receiver because when passed to a function
> declared as taking an interface a copy is made (and a reference to the copy
> held). This copy is implicit not explicit.
>

Yes. But (as the FAQ entry points out) copying values when passing is how
Go works in general.


> This is a difficult model when working on large multi person projects -
> thus the “best practice” of using only pointer or value receivers I think.
> Suggesting that the linter flags code not adhering to this seems to have
> very little downside if any.
>

It has the downside of flagging correct code as incorrect.

A quick search on the web (and the faq language) makes me think I am not
> alone in this opinion.
>
> I guess I still don’t see the downside to linter changes. As I said I
> reviewed a lot of the stdlib and I don’t see any obvious mixed receiver
> structs. They can be disabled on a per struct basis if needed.
>
> Anyway it was just my opinion based on my experiences.
>
> On Jun 7, 2021, at 6:05 PM, Axel Wagner 
> wrote:
>
> 
> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels 
> wrote:
>
>> I don’t think that represents the problem fairly. In the non interface
>> case I know I can’t accept a copy so I would declare the method as taking a
>> pointer to the struct.
>>
>
> How methods are declared should, in general, not be a matter of whether or
> not they are assigned to an interface, but to whether or not they need a
> pointer. Again: Your code is incorrect without interfaces
> . The problem doesn't happen when
> you put that value into an interface - it happens when you pass a copy of
> it and expect it to refer to the original. Interfaces are just one way to
> create such a copy, but they do not matter for the correctness of this code
> and for whether or not that method needs a pointer receiver (it does).
>
> But again, to be clear: I'm not saying problems like this *never* happen
> and I'm not even saying that interfaces may obscure it in some cases. Just
> that a) the root cause here is that your method really needs to take a
> pointer-receiver, interfaces or not and b) that it seems very much an
> overstatement to me to call this "the most inconsistent and obtuse aspect
> of the Go language".
>
> With interfaces this is lost - as the interface is implicitly a pointer
>>
>
> Well, it seems a bad idea to say that interfaces are implicitly pointers
> then. That seems to indicate that Rob's original phrasing is indeed an
> important clarification - the language behaves as if the value contained in
> them is copied when the interface value is copied.
>
> It seems the confusion here is, that you assume it's not. And that
> interfaces act as a pointers, when they don't.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG%3DT4fdNHvpT--aY1v9mTr9GrZp-iTkfM6Cy51-Gq-sGA%40mail.gmail.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 1:26 AM Robert Engels  wrote:

> The pattern of a background stats collector is a common one. The atomic is
> required not optional.
>

It might be a common pattern, but it uses a pointer-receiver in that case.
The atomic operation is not required, it operates on a local variable.
Again, I don't understand how you can make statements that are so clearly
wrong.

Feel free to try running it in the race detector without an atomic
operation. Feel free trying to get the race detector to trigger without the
atomic access, but keeping it silent when you add it. You'll find that this
needs a pointer receiver. Because otherwise the function is operating on a
local variable.


>
> On Jun 7, 2021, at 6:16 PM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> BTW, just to nail down the point of that code being wrong without
> interfaces: Your usage of `atomic` in `Log` is superfluous. You are
> operating on a local variable, so there is no possibility of concurrent
> modification. Your code is equivalent to this:
> https://play.golang.org/p/zYG0zTsk-2a
> The only reason to use `atomic` here (and why you used it) is if that
> memory could be shared between goroutines. For that to happen, you need a
> pointer receiver though.
>
> I refuse to believe that interfaces have anything to do with this
> obfuscation here. There is more than enough indication of it being wrong in
> any case.
>
> On Tue, Jun 8, 2021 at 1:05 AM Axel Wagner 
> wrote:
>
>> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels 
>> wrote:
>>
>>> I don’t think that represents the problem fairly. In the non interface
>>> case I know I can’t accept a copy so I would declare the method as taking a
>>> pointer to the struct.
>>>
>>
>> How methods are declared should, in general, not be a matter of whether
>> or not they are assigned to an interface, but to whether or not they need a
>> pointer. Again: Your code is incorrect without interfaces
>> . The problem doesn't happen when
>> you put that value into an interface - it happens when you pass a copy of
>> it and expect it to refer to the original. Interfaces are just one way to
>> create such a copy, but they do not matter for the correctness of this code
>> and for whether or not that method needs a pointer receiver (it does).
>>
>> But again, to be clear: I'm not saying problems like this *never* happen
>> and I'm not even saying that interfaces may obscure it in some cases. Just
>> that a) the root cause here is that your method really needs to take a
>> pointer-receiver, interfaces or not and b) that it seems very much an
>> overstatement to me to call this "the most inconsistent and obtuse aspect
>> of the Go language".
>>
>> With interfaces this is lost - as the interface is implicitly a pointer
>>>
>>
>> Well, it seems a bad idea to say that interfaces are implicitly pointers
>> then. That seems to indicate that Rob's original phrasing is indeed an
>> important clarification - the language behaves as if the value contained in
>> them is copied when the interface value is copied.
>>
>> It seems the confusion here is, that you assume it's not. And that
>> interfaces act as a pointers, when they don't.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGVyvYYpQhCp_JkxN9EvgZ4FXJ8_WpxseJOB1OR7qt6ww%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHibUpDHQU9m8%3DrLYtnDj%3DFY01nkuP4k0Giow-hCbhNgQ%40mail.gmail.com.

[go-nuts] Re: Surprising benchmark result

[tapi...@gmail.com]

On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:

> name   time/op
> Filter3-4  1.38µs ± 0%
> Filter4-4  1.39µs ± 0%
>
>
What is your CPU model?
 

>
> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The code: https://play.golang.org/p/DxUj6kBqf8k
>>
>> The Filter4 function has one more assignment statement than Filter3.
>> But the benchmark result shows Filter4 is faster than Filter3.
>>
>> The result:
>>
>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>> BenchmarkFilter3-43575656   980.2 ns/op   0 
>> B/op   0 allocs/op
>> BenchmarkFilter4-43956533   916.8 ns/op   0 
>> B/op   0 allocs/op
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f62c53b8-7daf-4619-9e81-9783a4ee1903n%40googlegroups.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

We agree. It needs a pointer receiver to work. The atomic is also needed in 
this case for background logging. 

The problem in this case is that recordEvents() has to document that the  
EventLogger passed to recordEvents() must have a pointer receiver for the Log() 
method. There is nothing in the language that allows me to declare it nor the 
compiler to enforce it.

If you don’t see this as suboptimal and an area for improvement I am not sure 
what else I can say.

And by the way, linters often flag correct code - that is why they have disable 
options. They try to enforce the most common cases - and by the recommendation 
in the faq to only use receivers of the same type - it seems appropriate to me 
to have the linter flag this. 

As to this being in my opinion the most inconsistent and obtuse aspect of Go - 
that is my opinion. Curious, what do you think would take the top spot?


> On Jun 7, 2021, at 6:34 PM, Axel Wagner  wrote:
> 
> 
>> On Tue, Jun 8, 2021 at 1:26 AM Robert Engels  wrote:
> 
>> The pattern of a background stats collector is a common one. The atomic is 
>> required not optional. 
> 
> It might be a common pattern, but it uses a pointer-receiver in that case. 
> The atomic operation is not required, it operates on a local variable. Again, 
> I don't understand how you can make statements that are so clearly wrong.
> 
> Feel free to try running it in the race detector without an atomic operation. 
> Feel free trying to get the race detector to trigger without the atomic 
> access, but keeping it silent when you add it. You'll find that this needs a 
> pointer receiver. Because otherwise the function is operating on a local 
> variable.
>  
>> 
 On Jun 7, 2021, at 6:16 PM, 'Axel Wagner' via golang-nuts 
  wrote:
 
>>> 
>>> BTW, just to nail down the point of that code being wrong without 
>>> interfaces: Your usage of `atomic` in `Log` is superfluous. You are 
>>> operating on a local variable, so there is no possibility of concurrent 
>>> modification. Your code is equivalent to this: 
>>> https://play.golang.org/p/zYG0zTsk-2a
>>> The only reason to use `atomic` here (and why you used it) is if that 
>>> memory could be shared between goroutines. For that to happen, you need a 
>>> pointer receiver though.
>>> 
>>> I refuse to believe that interfaces have anything to do with this 
>>> obfuscation here. There is more than enough indication of it being wrong in 
>>> any case.
>>> 
 On Tue, Jun 8, 2021 at 1:05 AM Axel Wagner  
 wrote:
> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels  
> wrote:
 
> I don’t think that represents the problem fairly. In the non interface 
> case I know I can’t accept a copy so I would declare the method as taking 
> a pointer to the struct.
 
 How methods are declared should, in general, not be a matter of whether or 
 not they are assigned to an interface, but to whether or not they need a 
 pointer. Again: Your code is incorrect without interfaces. The problem 
 doesn't happen when you put that value into an interface - it happens when 
 you pass a copy of it and expect it to refer to the original. Interfaces 
 are just one way to create such a copy, but they do not matter for the 
 correctness of this code and for whether or not that method needs a 
 pointer receiver (it does).
 
 But again, to be clear: I'm not saying problems like this *never* happen 
 and I'm not even saying that interfaces may obscure it in some cases. Just 
 that a) the root cause here is that your method really needs to take a 
 pointer-receiver, interfaces or not and b) that it seems very much an 
 overstatement to me to call this "the most inconsistent and obtuse aspect 
 of the Go language".
 
> With interfaces this is lost - as the interface is implicitly a pointer
 
 Well, it seems a bad idea to say that interfaces are implicitly pointers 
 then. That seems to indicate that Rob's original phrasing is indeed an 
 important clarification - the language behaves as if the value contained 
 in them is copied when the interface value is copied.
 
 It seems the confusion here is, that you assume it's not. And that 
 interfaces act as a pointers, when they don't.
>>> 
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGVyvYYpQhCp_JkxN9EvgZ4FXJ8_WpxseJOB1OR7qt6ww%40mail.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.
> To view this discussion on th

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 2:05 AM Robert Engels  wrote:

>
> We agree. It needs a pointer receiver to work. The atomic is also needed
> in this case for background logging.
>
> The problem in this case is that recordEvents() has to document that the
>  EventLogger passed to recordEvents() must have a pointer receiver for the
> Log() method. There is nothing in the language that allows me to declare it
> nor the compiler to enforce it.
>

It is possible to write a working implementation of that interface without
a pointer receiver - it just needs to *contain* a pointer:
https://play.golang.org/p/Xm6ASGcCyhR
You could also have a slice type, which also can do modifications without a
pointer receiver. Or a map-type. Or a channel.

If you would restrict an interface to require pointer-receiver, you would
wrongly restrict the implementer from all these possibilities.

As is the common wisdom, the user of an interface should not care what the
concrete type implementing an interface is (except if it needs to do a
type-assertions). It's the same wisdom that applies to people wanting to
check if an interface contains a nil-pointer: That check relies on the
assumption that the interface contains a pointer, which shouldn't be nil
and that's not something that should concern the user of an interface.

Again, to be abundantly clear (you still seem unwilling to acknowledge
this): The problem with your code is not the definition or usage of the
interface. It's the definition of the method that is wrong. The
interface-definition is fine and works fine.

If you don’t see this as suboptimal and an area for improvement I am not
> sure what else I can say.
>

I just want to state again, clearly, that all I objected to was you calling
this "the most inconsistent and obtuse aspect of the Go language", which I
perceived (and still do) to be an overstatement. "It is suboptimal" or "it
is an area of improvement" are both significantly weaker statements, which
I find less objectionable.

Personally, I still don't think it is a huge problem. And the fact that you
where having a lot of trouble coming up with an example showing it to be
one (the one you posted doesn't - again, it doesn't, in any way, change
behavior when using or not using interfaces) is, in my view, a testament to
that.

And by the way, linters often flag correct code - that is why they have
> disable options. They try to enforce the most common cases - and by the
> recommendation in the faq to only use receivers of the same type - it seems
> appropriate to me to have the linter flag this.
>

I'm opposed to a linter flag, because it would flag correct code I
regularly write. In general, linters should not be ignored - they either
shouldn't be run, or they should be followed. Note that golint has no
option to selectively disable a particular instance of a warning - the only
way to silence a warning is to change the code. But I don't want to use a
pointer receiver, if a value receiver is more appropriate.

If golint or go vet would start flagging this, I would likely follow the
advice it's giving. Because that's how linters and static checks are
supposed to be used - to enforce consistency. But I'd be sad doing it.
Which is why I don't want them to flag it.

I'm less opposed to the FAQ entry. Simpy because an FAQ entry can be more
easily ignored where it makes sense. If you will, it is one step in
stringency below a linter. I'm fine defending my choice in a code review,
but I don't want to defend it to a linter.


> As to this being in my opinion the most inconsistent and obtuse aspect of
> Go - that is my opinion. Curious, what do you think would take the top spot?
>

I'm not sure. I don't like putting things in absolute order or claiming
something is "the most X" for exactly that reason - it almost always turns
out to be an overstatement.

Empirically, the issue of nil-pointers in interfaces not being nil seems to
take one of the top spots, even though I don't fully understand why.
To me, concurrency in Go is extremely subtle and I would generally advice
novices to stay away from it at first (or stay with extremely simple
constructs), because they are likely to get it wrong.
Details of how Go handles constants and type-identity/assignabiity is what
is probably most often tripping me, personally, up in questions/quizzes
about Go. But it rarely comes up in practice.
The lack of co/contravariance is probably one of the things I miss the most
from the language.

It really depends on what you're asking. And I'm very likely forgetting
things while being put on the spot.
It's just a lot easier to make relative judgments, than absolute ones.


>
> On Jun 7, 2021, at 6:34 PM, Axel Wagner 
> wrote:
>
> 
> On Tue, Jun 8, 2021 at 1:26 AM Robert Engels 
> wrote:
>
>> The pattern of a background stats collector is a common one. The atomic
>> is required not optional.
>>
>
> It might be a common pattern, but it uses a pointer-receiver in that case.
> The atomic operation is not requi

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* 'Axel Wagner' via golang-nuts  [210607 19:06]:
> Well, it seems a bad idea to say that interfaces are implicitly pointers
> then. That seems to indicate that Rob's original phrasing is indeed an
> important clarification - the language behaves as if the value contained in
> them is copied when the interface value is copied.

I agree with most of what you are saying to Robert Engels, but I
disagree with this.  The FAQ needs to make it clear that making a copy
of the value happens when assigning a concrete value to an interface and
when extracting a concrete value from an interface, but that the
interface passed around does _not_ require the allocation overhead of
copying the concrete value every time the interface is copied (even if
it behaves, whenever the interface is used, as if a copy is made).

It is clear from this thread that this is a confusing topic, and also
that programmers new to Go are reading this FAQ entry and believing,
incorrectly, that to optimize memory allocations they should use
pointers when it is not necessary to do so.

In other words, there are two distinct aspects that both need to be
expounded in the FAQ:  the external behavior and the performance-related
consequences.  People are jumping to the wrong conclusion because the
FAQ says "copying the interface value makes a copy of the struct".  This
is simply untrue, and not necessary according to the language spec.

The correct statement is that "copying the interface value behaves as if
the struct is copied without actually needing to make a new copy of the
struct".  That second part is important.

...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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210608004229.3s3ftgrdy47guhic%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

(I think you pasted the wrong link - that is my code). 

It is not about being unwilling to admit it. Your explanation/reasoning has not 
convinced me. 

Imagine some library declares the EventLogger interface as shown. Acceptable. 
Someone writes the RecordEvents() method taking an EventLogger. Acceptable. 

Now, I have a struct I want to use with as an EventLogger (badly named - really 
EventSource). The code I wrote works fine. Test cases (of Log()) work fine. It 
fails when used as a source to RecordEvents() (and similar held reference 
patterns). 

How do you protect against this? What is the mechanism as a library author?

Clearly this is a trivial example but similar patterns are everywhere. 

Compare the Go interface handling with Java’s everything is a reference - much 
simpler - and then adding value types that are explicit. Or a similar 
implementation in Rust. In both cases knowing you wrote a correct 
implementation is much easier. Java has since added annotations for aspects 
like “thread safe” that cover the atomic aspects. 

I like Go. A lot. I’ve designed and built systems with millions of LOC. 
Pointing out aspects that might benefit from changes should be encouraged - if 
not it’s a religion not a programming language. 

> On Jun 7, 2021, at 7:40 PM, Axel Wagner  wrote:
> 
> 
> 
> 
>> On Tue, Jun 8, 2021 at 2:05 AM Robert Engels  wrote:
>> 
>> We agree. It needs a pointer receiver to work. The atomic is also needed in 
>> this case for background logging. 
>> 
>> The problem in this case is that recordEvents() has to document that the  
>> EventLogger passed to recordEvents() must have a pointer receiver for the 
>> Log() method. There is nothing in the language that allows me to declare it 
>> nor the compiler to enforce it.
> 
> It is possible to write a working implementation of that interface without a 
> pointer receiver - it just needs to *contain* a pointer: 
> https://play.golang.org/p/Xm6ASGcCyhR
> You could also have a slice type, which also can do modifications without a 
> pointer receiver. Or a map-type. Or a channel.
> 
> If you would restrict an interface to require pointer-receiver, you would 
> wrongly restrict the implementer from all these possibilities.
> 
> As is the common wisdom, the user of an interface should not care what the 
> concrete type implementing an interface is (except if it needs to do a 
> type-assertions). It's the same wisdom that applies to people wanting to 
> check if an interface contains a nil-pointer: That check relies on the 
> assumption that the interface contains a pointer, which shouldn't be nil and 
> that's not something that should concern the user of an interface.
> 
> Again, to be abundantly clear (you still seem unwilling to acknowledge this): 
> The problem with your code is not the definition or usage of the interface. 
> It's the definition of the method that is wrong. The interface-definition is 
> fine and works fine.
> 
>> If you don’t see this as suboptimal and an area for improvement I am not 
>> sure what else I can say.
> 
> I just want to state again, clearly, that all I objected to was you calling 
> this "the most inconsistent and obtuse aspect of the Go language", which I 
> perceived (and still do) to be an overstatement. "It is suboptimal" or "it is 
> an area of improvement" are both significantly weaker statements, which I 
> find less objectionable.
>  
> Personally, I still don't think it is a huge problem. And the fact that you 
> where having a lot of trouble coming up with an example showing it to be one 
> (the one you posted doesn't - again, it doesn't, in any way, change behavior 
> when using or not using interfaces) is, in my view, a testament to that.
> 
>> And by the way, linters often flag correct code - that is why they have 
>> disable options. They try to enforce the most common cases - and by the 
>> recommendation in the faq to only use receivers of the same type - it seems 
>> appropriate to me to have the linter flag this. 
> 
> I'm opposed to a linter flag, because it would flag correct code I regularly 
> write. In general, linters should not be ignored - they either shouldn't be 
> run, or they should be followed. Note that golint has no option to 
> selectively disable a particular instance of a warning - the only way to 
> silence a warning is to change the code. But I don't want to use a pointer 
> receiver, if a value receiver is more appropriate.
> 
> If golint or go vet would start flagging this, I would likely follow the 
> advice it's giving. Because that's how linters and static checks are supposed 
> to be used - to enforce consistency. But I'd be sad doing it. Which is why I 
> don't want them to flag it.
> 
> I'm less opposed to the FAQ entry. Simpy because an FAQ entry can be more 
> easily ignored where it makes sense. If you will, it is one step in 
> stringency below a linter. I'm fine defending my choice in a code review, but 
> I don't want to defend it to a linter.
>  
>>

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Robert Engels]

Sorry - correct link. I missed the subtle change.

> On Jun 7, 2021, at 8:18 PM, Robert Engels  wrote:
> 
> 
> (I think you pasted the wrong link - that is my code). 
> 
> It is not about being unwilling to admit it. Your explanation/reasoning has 
> not convinced me. 
> 
> Imagine some library declares the EventLogger interface as shown. Acceptable. 
> Someone writes the RecordEvents() method taking an EventLogger. Acceptable. 
> 
> Now, I have a struct I want to use with as an EventLogger (badly named - 
> really EventSource). The code I wrote works fine. Test cases (of Log()) work 
> fine. It fails when used as a source to RecordEvents() (and similar held 
> reference patterns). 
> 
> How do you protect against this? What is the mechanism as a library author?
> 
> Clearly this is a trivial example but similar patterns are everywhere. 
> 
> Compare the Go interface handling with Java’s everything is a reference - 
> much simpler - and then adding value types that are explicit. Or a similar 
> implementation in Rust. In both cases knowing you wrote a correct 
> implementation is much easier. Java has since added annotations for aspects 
> like “thread safe” that cover the atomic aspects. 
> 
> I like Go. A lot. I’ve designed and built systems with millions of LOC. 
> Pointing out aspects that might benefit from changes should be encouraged - 
> if not it’s a religion not a programming language. 
> 
>>> On Jun 7, 2021, at 7:40 PM, Axel Wagner  
>>> wrote:
>>> 
>> 
>> 
>> 
>>> On Tue, Jun 8, 2021 at 2:05 AM Robert Engels  wrote:
>>> 
>>> We agree. It needs a pointer receiver to work. The atomic is also needed in 
>>> this case for background logging. 
>>> 
>>> The problem in this case is that recordEvents() has to document that the  
>>> EventLogger passed to recordEvents() must have a pointer receiver for the 
>>> Log() method. There is nothing in the language that allows me to declare it 
>>> nor the compiler to enforce it.
>> 
>> It is possible to write a working implementation of that interface without a 
>> pointer receiver - it just needs to *contain* a pointer: 
>> https://play.golang.org/p/Xm6ASGcCyhR
>> You could also have a slice type, which also can do modifications without a 
>> pointer receiver. Or a map-type. Or a channel.
>> 
>> If you would restrict an interface to require pointer-receiver, you would 
>> wrongly restrict the implementer from all these possibilities.
>> 
>> As is the common wisdom, the user of an interface should not care what the 
>> concrete type implementing an interface is (except if it needs to do a 
>> type-assertions). It's the same wisdom that applies to people wanting to 
>> check if an interface contains a nil-pointer: That check relies on the 
>> assumption that the interface contains a pointer, which shouldn't be nil and 
>> that's not something that should concern the user of an interface.
>> 
>> Again, to be abundantly clear (you still seem unwilling to acknowledge 
>> this): The problem with your code is not the definition or usage of the 
>> interface. It's the definition of the method that is wrong. The 
>> interface-definition is fine and works fine.
>> 
>>> If you don’t see this as suboptimal and an area for improvement I am not 
>>> sure what else I can say.
>> 
>> I just want to state again, clearly, that all I objected to was you calling 
>> this "the most inconsistent and obtuse aspect of the Go language", which I 
>> perceived (and still do) to be an overstatement. "It is suboptimal" or "it 
>> is an area of improvement" are both significantly weaker statements, which I 
>> find less objectionable.
>>  
>> Personally, I still don't think it is a huge problem. And the fact that you 
>> where having a lot of trouble coming up with an example showing it to be one 
>> (the one you posted doesn't - again, it doesn't, in any way, change behavior 
>> when using or not using interfaces) is, in my view, a testament to that.
>> 
>>> And by the way, linters often flag correct code - that is why they have 
>>> disable options. They try to enforce the most common cases - and by the 
>>> recommendation in the faq to only use receivers of the same type - it seems 
>>> appropriate to me to have the linter flag this. 
>> 
>> I'm opposed to a linter flag, because it would flag correct code I regularly 
>> write. In general, linters should not be ignored - they either shouldn't be 
>> run, or they should be followed. Note that golint has no option to 
>> selectively disable a particular instance of a warning - the only way to 
>> silence a warning is to change the code. But I don't want to use a pointer 
>> receiver, if a value receiver is more appropriate.
>> 
>> If golint or go vet would start flagging this, I would likely follow the 
>> advice it's giving. Because that's how linters and static checks are 
>> supposed to be used - to enforce consistency. But I'd be sad doing it. Which 
>> is why I don't want them to flag it.
>> 
>> I'm less opposed to the FAQ entry. 

[go-nuts] Re: Surprising benchmark result

[peterGo]

i7-7500U
name   time/op
Filter3-4  1.38µs ± 0%
Filter4-4  1.39µs ± 0%

i5-8250U
name   time/op
Filter3-8  1.37µs ± 0%
Filter4-8  1.39µs ± 0%


On Monday, June 7, 2021 at 7:42:43 PM UTC-4 tapi...@gmail.com wrote:

> On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:
>
>> name   time/op
>> Filter3-4  1.38µs ± 0%
>> Filter4-4  1.39µs ± 0%
>>
>>
> What is your CPU model?
>  
>
>>
>> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> The code: https://play.golang.org/p/DxUj6kBqf8k
>>>
>>> The Filter4 function has one more assignment statement than Filter3.
>>> But the benchmark result shows Filter4 is faster than Filter3.
>>>
>>> The result:
>>>
>>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>>> BenchmarkFilter3-43575656   980.2 ns/op   0 
>>> B/op   0 allocs/op
>>> BenchmarkFilter4-43956533   916.8 ns/op   0 
>>> B/op   0 allocs/op
>>>
>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f6bc1b35-d31a-4692-acaf-24e06af7c293n%40googlegroups.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Marvin Renich]

* Robert Engels  [210607 21:18]:
> (I think you pasted the wrong link - that is my code). 

subsequent correction acknowledged; assuming the following discussion is
about https://play.golang.org/p/-f73t_Pm7ur

> It is not about being unwilling to admit it. Your
> explanation/reasoning has not convinced me. 
> 
> Imagine some library declares the EventLogger interface as shown.
> Acceptable. Someone writes the RecordEvents() method taking an
> EventLogger. Acceptable. 
> 
> Now, I have a struct I want to use with as an EventLogger (badly named
> - really EventSource). The code I wrote works fine. Test cases (of
> Log()) work fine. It fails when used as a source to RecordEvents()
> (and similar held reference patterns). 

I have to agree with Axel.  This code is not fine, and it is easy to at
least notice that it is suspect, even if it requires more careful
examination to determine that it is wrong.  The fact that the Log method
has a value receiver and the Inc method has a pointer receiver is a very
obvious clue that this code needs careful review.  Next, Log takes a
value receiver, but is using synchronization (whether it is atomic or
mutex doesn't matter); this should be where the programmer realizes that
the code is broken.  And, as Axel keeps saying, it has nothing to do
with interfaces; the method on the struct is broken without any
interface being involved.

You say that test cases of Log work fine, but they are only fine in a
non-concurrent environment.  The instant you test Log (without
interfaces) in a concurrent program it fails in an obvious manner.

Interfaces, and their ability to potentially be satisfied by either a
non-pointer type or a pointer type, depending on the type, is not the
problem here.

...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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210608043609.gguu3t3hqbsziema%40basil.wdw.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 3:16 AM Robert Engels  wrote:

> Now, I have a struct I want to use with as an EventLogger (badly named -
> really EventSource). The code I wrote works fine. Test cases (of Log())
> work fine.
>

This is where the refusal to acknowledge comes in. It does not work fine. I
don't understand how you can look at the code without interfaces
, run it, see that it behaves
*exactly* the same as your code with interfaces
 and still make a statement that
this code works fine. This isn't a matter of being convincing. I'm not
making an argument here. The code you wrote to show that the method is
broken shows that it's broken if you use interfaces or not. How can you
look at that and deny that the code executes the way it does, when you can
actually run it for yourself?

If you wrote tests for those methods and those tests passed, then clearly
your tests are insufficient. Because you, personally, have posted a test
case in this thread, which shows that the `Log` method does *not* work
fine. Without any interfaces.

That's what baffles me. How you can hold on to the narrative that the code
without interfaces works fine and the code with interfaces breaks, when
that's so easily verifiable and shown to be false, just by clicking "Run"
on the playground.

Even if you would try to make the argument (but, again, you are simply
refusing to even acknowledge, you aren't even making a counter argument)
that the tests without interfaces would use a pointer
 (but that's changing more than just
whether or not you are using interfaces - and if you do the same change
using interfaces you again get the same execution trace), all that's needed
to still see that's broken is to run it using `-race`.

There is no opinion here. These are easily verifiable facts. Just repeating
"the code works fine" doesn't change the fact that people can run it and
see that it's not.

It fails when used as a source to RecordEvents() (and similar held
> reference patterns).
>
> How do you protect against this? What is the mechanism as a library author?
>
> Clearly this is a trivial example but similar patterns are everywhere.
>
> Compare the Go interface handling with Java’s everything is a reference -
> much simpler - and then adding value types that are explicit. Or a similar
> implementation in Rust. In both cases knowing you wrote a correct
> implementation is much easier. Java has since added annotations for aspects
> like “thread safe” that cover the atomic aspects.
>
> I like Go. A lot. I’ve designed and built systems with millions of LOC.
> Pointing out aspects that might benefit from changes should be encouraged -
> if not it’s a religion not a programming language.
>
> On Jun 7, 2021, at 7:40 PM, Axel Wagner 
> wrote:
>
> 
>
>
> On Tue, Jun 8, 2021 at 2:05 AM Robert Engels 
> wrote:
>
>>
>> We agree. It needs a pointer receiver to work. The atomic is also needed
>> in this case for background logging.
>>
>> The problem in this case is that recordEvents() has to document that the
>>  EventLogger passed to recordEvents() must have a pointer receiver for the
>> Log() method. There is nothing in the language that allows me to declare it
>> nor the compiler to enforce it.
>>
>
> It is possible to write a working implementation of that interface without
> a pointer receiver - it just needs to *contain* a pointer:
> https://play.golang.org/p/Xm6ASGcCyhR
> You could also have a slice type, which also can do modifications without
> a pointer receiver. Or a map-type. Or a channel.
>
> If you would restrict an interface to require pointer-receiver, you would
> wrongly restrict the implementer from all these possibilities.
>
> As is the common wisdom, the user of an interface should not care what the
> concrete type implementing an interface is (except if it needs to do a
> type-assertions). It's the same wisdom that applies to people wanting to
> check if an interface contains a nil-pointer: That check relies on the
> assumption that the interface contains a pointer, which shouldn't be nil
> and that's not something that should concern the user of an interface.
>
> Again, to be abundantly clear (you still seem unwilling to acknowledge
> this): The problem with your code is not the definition or usage of the
> interface. It's the definition of the method that is wrong. The
> interface-definition is fine and works fine.
>
> If you don’t see this as suboptimal and an area for improvement I am not
>> sure what else I can say.
>>
>
> I just want to state again, clearly, that all I objected to was you
> calling this "the most inconsistent and obtuse aspect of the Go language",
> which I perceived (and still do) to be an overstatement. "It is suboptimal"
> or "it is an area of improvement" are both significantly weaker statements,
> which I find less objectionable.
>
> Personally, I still don't think it is a huge problem. And t

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 3:16 AM Robert Engels  wrote:

> I like Go. A lot. I’ve designed and built systems with millions of LOC.
> Pointing out aspects that might benefit from changes should be encouraged -
> if not it’s a religion not a programming language.
>

FTR, this is the second time you are making that twist and I already called
out the first and I don't appreciate that you are repeating it.

"This aspect might benefit from a change" is a significantly weaker
statement that using a superlative like "the most inconsistent and obtuse
aspect of the Go language".


>
> On Jun 7, 2021, at 7:40 PM, Axel Wagner 
> wrote:
>
> 
>
>
> On Tue, Jun 8, 2021 at 2:05 AM Robert Engels 
> wrote:
>
>>
>> We agree. It needs a pointer receiver to work. The atomic is also needed
>> in this case for background logging.
>>
>> The problem in this case is that recordEvents() has to document that the
>>  EventLogger passed to recordEvents() must have a pointer receiver for the
>> Log() method. There is nothing in the language that allows me to declare it
>> nor the compiler to enforce it.
>>
>
> It is possible to write a working implementation of that interface without
> a pointer receiver - it just needs to *contain* a pointer:
> https://play.golang.org/p/Xm6ASGcCyhR
> You could also have a slice type, which also can do modifications without
> a pointer receiver. Or a map-type. Or a channel.
>
> If you would restrict an interface to require pointer-receiver, you would
> wrongly restrict the implementer from all these possibilities.
>
> As is the common wisdom, the user of an interface should not care what the
> concrete type implementing an interface is (except if it needs to do a
> type-assertions). It's the same wisdom that applies to people wanting to
> check if an interface contains a nil-pointer: That check relies on the
> assumption that the interface contains a pointer, which shouldn't be nil
> and that's not something that should concern the user of an interface.
>
> Again, to be abundantly clear (you still seem unwilling to acknowledge
> this): The problem with your code is not the definition or usage of the
> interface. It's the definition of the method that is wrong. The
> interface-definition is fine and works fine.
>
> If you don’t see this as suboptimal and an area for improvement I am not
>> sure what else I can say.
>>
>
> I just want to state again, clearly, that all I objected to was you
> calling this "the most inconsistent and obtuse aspect of the Go language",
> which I perceived (and still do) to be an overstatement. "It is suboptimal"
> or "it is an area of improvement" are both significantly weaker statements,
> which I find less objectionable.
>
> Personally, I still don't think it is a huge problem. And the fact that
> you where having a lot of trouble coming up with an example showing it to
> be one (the one you posted doesn't - again, it doesn't, in any way, change
> behavior when using or not using interfaces) is, in my view, a testament to
> that.
>
> And by the way, linters often flag correct code - that is why they have
>> disable options. They try to enforce the most common cases - and by the
>> recommendation in the faq to only use receivers of the same type - it seems
>> appropriate to me to have the linter flag this.
>>
>
> I'm opposed to a linter flag, because it would flag correct code I
> regularly write. In general, linters should not be ignored - they either
> shouldn't be run, or they should be followed. Note that golint has no
> option to selectively disable a particular instance of a warning - the only
> way to silence a warning is to change the code. But I don't want to use a
> pointer receiver, if a value receiver is more appropriate.
>
> If golint or go vet would start flagging this, I would likely follow the
> advice it's giving. Because that's how linters and static checks are
> supposed to be used - to enforce consistency. But I'd be sad doing it.
> Which is why I don't want them to flag it.
>
> I'm less opposed to the FAQ entry. Simpy because an FAQ entry can be more
> easily ignored where it makes sense. If you will, it is one step in
> stringency below a linter. I'm fine defending my choice in a code review,
> but I don't want to defend it to a linter.
>
>
>> As to this being in my opinion the most inconsistent and obtuse aspect of
>> Go - that is my opinion. Curious, what do you think would take the top spot?
>>
>
> I'm not sure. I don't like putting things in absolute order or claiming
> something is "the most X" for exactly that reason - it almost always turns
> out to be an overstatement.
>
> Empirically, the issue of nil-pointers in interfaces not being nil seems
> to take one of the top spots, even though I don't fully understand why.
> To me, concurrency in Go is extremely subtle and I would generally advice
> novices to stay away from it at first (or stay with extremely simple
> constructs), because they are likely to get it wrong.
> Details of how Go handles con

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

['Axel Wagner' via golang-nuts]

On Tue, Jun 8, 2021 at 6:36 AM Marvin Renich  wrote:

> You say that test cases of Log work fine, but they are only fine in a
> non-concurrent environment.  The instant you test Log (without
> interfaces) in a concurrent program it fails in an obvious manner.
>

nit: I don't think concurrency has anything to do with it either. The
failure mode is making a copy and expecting the copy and the original to
share memory. If anything, concurrency (in a test) would make it more
likely to get hidden, by increasing the likelihood that a closure is used,
which implicitly shares a pointer: https://play.golang.org/p/Gwj9GScjQBJ

Of course, concurrency then also makes the failure easy to see, as long as
you remember to run your tests with `-race`.

FWIW I agree with Robert that it's relatively easy to write a test for this
that never copies the value (though even then, if you think about using
atomics you definitely should think about writing a concurrent test and
running it with `-race` enabled, which should show the problem).
I disagree with him, however, that interfaces make it more likely to run
into the problem when *using* the code. Any even remotely realistic usage
of that code is broken. Even if you failed to write tests which surface
that breakage.


> Interfaces, and their ability to potentially be satisfied by either a
> non-pointer type or a pointer type, depending on the type, is not the
> problem here.
>
> ...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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20210608043609.gguu3t3hqbsziema%40basil.wdw
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGa5B99OO8oTxJOWFSuJPinPF3b1QJWEuqMD4ZPAiCi%3DQ%40mail.gmail.com.