Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Robert Engels
I will re-iterate, this is something large distributed development teams have struggled with for a long-time - it's my experience that diffs that ignore formatting changes and provide "contextual changes" are far easier to use - especially for code reviews.If you are performing reviews using line by line diffs you're really missing out (and creating a lot more work).If you ever used the Eclipse Java code changes review you'll know exactly what I mean.-Original Message-
From: Manlio Perillo 
Sent: Feb 20, 2020 4:53 PM
To: golang-nuts 
Subject: Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

On Thursday, February 20, 2020 at 3:52:40 PM UTC+1, ohir wrote:Dnia 2020-02-20, o godz. 08:57:51
David Riley <frave...@gmail.com> napisał(a):

> I'm willing to be convinced otherwise.  [...] 
> a new "magic" tab that won't be supported

This proposal is not about some "magic tab". It is about a gofmt formatting recipe
that allows for minimal changesets while keeping "pretty" autoformatting of structs
intact. ("Smart tabs" were mentioned by Manilo in other thread. :)

I proposed to use a tab in order for gofmt to recognize it and not reformat that field.If we use a space, gofmt will not work correctly on existing code that is already formatted and should not be reformatted.Maybe a better idea is to use a  U+00A0 NO-BREAK SPACE.  When gofmt see it, it should leave the formatting as is.There is still the problem with older versions of gofmt if the code is also modified by others, and the fact that NO-BREAK-SPACE is not easy to input.But gofmt may automatically insert it if it is used in the other fields.> [...]Manlio 



-- 
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/7d8a430a-b1d9-4d69-9814-0c8e39b3546f%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/1457147623.3471.1582241006928%40wamui-lola.atl.sa.earthlink.net.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Manlio Perillo
On Thursday, February 20, 2020 at 3:52:40 PM UTC+1, ohir wrote:
>
> Dnia 2020-02-20, o godz. 08:57:51 
> David Riley > napisał(a): 
>
> > I'm willing to be convinced otherwise.  [...] 
> > a new "magic" tab that won't be supported 
>
> This proposal is not about some "magic tab". It is about a gofmt 
> formatting recipe 
> that allows for minimal changesets while keeping "pretty" autoformatting 
> of structs 
> intact. ("Smart tabs" were mentioned by Manilo in other thread. :) 
>
>
I proposed to use a tab in order for gofmt to recognize it and not reformat 
that field.
If we use a space, gofmt will not work correctly on existing code that is 
already formatted and should not be reformatted.

Maybe a better idea is to use a  U+00A0 NO-BREAK SPACE.  When gofmt see it, 
it should leave the formatting as is.
There is still the problem with older versions of gofmt if the code is also 
modified by others, and the fact that NO-BREAK-SPACE is not easy to input.
But gofmt may automatically insert it if it is used in the other fields.

> [...]

Manlio 

-- 
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/7d8a430a-b1d9-4d69-9814-0c8e39b3546f%40googlegroups.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Wojciech S. Czarnecki
> ("Smart tabs" were mentioned by Manilo in other thread. :)

Uh, it was in this one, excuse me. Got both my and Manilo's mixed.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200220155535.5d9624ce%40xmint.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Wojciech S. Czarnecki
Dnia 2020-02-20, o godz. 08:57:51
David Riley  napisał(a):

> I'm willing to be convinced otherwise.  [...] 
> a new "magic" tab that won't be supported

This proposal is not about some "magic tab". It is about a gofmt formatting 
recipe
that allows for minimal changesets while keeping "pretty" autoformatting of 
structs
intact. ("Smart tabs" were mentioned by Manilo in other thread. :)

> Note that any change made is going to wind up producing 
> ENORMOUS superfluous diffs the first time anyone uses it 
> on existing code that's already been formatted,

This is the very reason for the "comment-mark" existence in this proposal.

Only new code will use it. Once you do a changes to the struct, you then may
chose new formatting as any change under old rules is going to produce
a massive changeset anyway.

Proposed recipe in fact needs none marker, it could as well used heuristics to 
set
csPos = tsPos  +8, or +16. Marker gives an opt-in switch here.

> - Dave
 
TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200220155204.0bbf9bcd%40xmint.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Robert Engels
Isn’t is easier to just set your diff display to ignore white space changes? 
Most modern IDEs have this option. 

> On Feb 20, 2020, at 7:59 AM, David Riley  wrote:
> 
> On Feb 20, 2020, at 8:35 AM, Manlio Perillo  wrote:
>> 
>> This is not a matter of style.  It is a matter of having clean diffs in 
>> commits.
> 
> It is both.
> 
> You may prioritize clean diffs, and I understand your reasons for that. Many 
> other people prioritize readability over clean diffs. Neither side is 
> *wrong*, because it's all subjective, but I think it would be better to get 
> some sense of how it would affect users either way before committing to a 
> path.  Otherwise, you will wind up with pitchforks and torches.
> 
> My belief is that the status quo is actually the best compromise, but I'm 
> willing to be convinced otherwise.  However, I'm unlikely to be convinced 
> that a new "magic" tab that won't be supported by the vast majority of 
> existing editors, terminals, printers, browsers and the like is going to be 
> the solution.
> 
> You could always split the baby and use a default tabstop of, say, 30 or 40 
> columns and let longer identifiers just run over. That's unlikely to really 
> satisfy anyone, but it's equally unlikely to dissatisfy folks to the extent 
> that changing to a single space will.
> 
> Note that any change made is going to wind up producing ENORMOUS superfluous 
> diffs the first time anyone uses it on existing code that's already been 
> formatted, not unlike the problem of converting hard tabs to spaces or vice 
> versa, so bear that in mind.
> 
> 
> - Dave
> 
> -- 
> 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/81701ED1-D431-4B36-8E6D-0E4FF8EB763C%40gmail.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/14795245-764E-400F-9706-BC5BEA5993ED%40ix.netcom.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread David Riley
On Feb 20, 2020, at 8:35 AM, Manlio Perillo  wrote:
> 
> This is not a matter of style.  It is a matter of having clean diffs in 
> commits.

It is both.

You may prioritize clean diffs, and I understand your reasons for that. Many 
other people prioritize readability over clean diffs. Neither side is *wrong*, 
because it's all subjective, but I think it would be better to get some sense 
of how it would affect users either way before committing to a path.  
Otherwise, you will wind up with pitchforks and torches.

My belief is that the status quo is actually the best compromise, but I'm 
willing to be convinced otherwise.  However, I'm unlikely to be convinced that 
a new "magic" tab that won't be supported by the vast majority of existing 
editors, terminals, printers, browsers and the like is going to be the solution.

You could always split the baby and use a default tabstop of, say, 30 or 40 
columns and let longer identifiers just run over. That's unlikely to really 
satisfy anyone, but it's equally unlikely to dissatisfy folks to the extent 
that changing to a single space will.

Note that any change made is going to wind up producing ENORMOUS superfluous 
diffs the first time anyone uses it on existing code that's already been 
formatted, not unlike the problem of converting hard tabs to spaces or vice 
versa, so bear that in mind.


- Dave

-- 
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/81701ED1-D431-4B36-8E6D-0E4FF8EB763C%40gmail.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Manlio Perillo

On Thursday, February 20, 2020 at 12:01:57 PM UTC+1, Amnon Baron Cohen 
wrote:
>
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. 
>> 
>
>
> From Go Proverbs.
>
> https://www.youtube.com/watch?v=PAAkCSZUG1c=8m43s
>
> Rob Pike answered this proposal in advance back in 2015.
>
> Wise words...
>

This is not a matter of style.  It is a matter of having clean diffs in 
commits.


Manlio

-- 
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/e3de1aeb-0deb-4412-b2dc-976493ece982%40googlegroups.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Amnon Baron Cohen

>
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite. 
> 


>From Go Proverbs.

https://www.youtube.com/watch?v=PAAkCSZUG1c=8m43s

Rob Pike answered this proposal in advance back in 2015.

Wise words...
 

-- 
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/e7a8e427-9611-4a58-8a96-de6c8a1d0de1%40googlegroups.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Wojciech S. Czarnecki
Dnia 2020-02-20, o godz. 09:10:22
Jan Mercl <0xj...@gmail.com> napisał(a):

> I believe the absence of any gofmt knobs (opt-ins) is a feature that's
> not going away. You can always use your private fork, if you want.
I do not want anymore ;)

Knob is there _mostly_ because of all the past code in millions of repos.
The fixed `csPos := tsPos += 8` would work for most of Go code w/o knob.

> most people will not accept code that is not formatted by the
> "standard" gofmt. 

Thats why it can be implemented "by the core team only".

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200220105559.507cdf03%40xmint.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Wojciech S. Czarnecki
Dnia 2020-02-20, o godz. 08:25:57
Amnon BC  napisał(a):

> Good point Jan, and I totally agree.
> 
> I noticed that the proposal states that it can only be implemented by the
> core team.
> 
> I don't really understand the statement, as go fmt is written in Go and all
> the sources are available online.

> So it might be worth expanding this statement to explain why this proposal
> can not be implemented by people outside the core team.

Because of what Jan mentioned: uniformity. Change of such kind must be agreed
upon then implemented thorough all community. The core team is the only entity
to wield such power.

I work with forked fmt and godoc (even compiler). Once you get hooked to such
settings you can not easily get out of it. You also unintentionally cut 
yourself from
easy ways to giving code back. That's a dead-end for an individual (though I 
must
admit that from the business pov it also may give a huge advantage over 
competitors).

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200220104922.671dddcc%40xmint.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Amnon BC
Good point Jan, and I totally agree.

I noticed that the proposal states that it can only be implemented by the
core team.

I don't really understand the statement, as go fmt is written in Go and all
the sources are available online.
So it might be worth expanding this statement to explain why this proposal
can not be implemented by
people outside the core team.

On Thu, Feb 20, 2020 at 8:11 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Feb 19, 2020 at 7:26 PM Wojciech S. Czarnecki 
> wrote:
>
> > https://github.com/golang/go/issues/37299
>
> "I propose to add an opt-in go fmt solution meant to minimize
> whitespace changes to the block where a code author hinted at desired
> comments position."
>
> I believe the absence of any gofmt knobs (opt-ins) is a feature that's
> not going away. You can always use your private fork, if you want. But
> most people will not accept code that is not formatted by the
> "standard" gofmt. Because again, the uniformity is the whole point of
> gofmt's existence.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/kp5-wX2ONdc/unsubscribe.
> To unsubscribe from this group and all its topics, 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-U%3DMomr0MMZcSpt5OdajMXF97G1XqmYhm8LLKVAiLXccA%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/CALg-z3U9Aya%3D2E4oUQNGU9HkdskkWSijsto1B%2B5NTsiyzu2%3DpA%40mail.gmail.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-20 Thread Jan Mercl
On Wed, Feb 19, 2020 at 7:26 PM Wojciech S. Czarnecki  wrote:

> https://github.com/golang/go/issues/37299

"I propose to add an opt-in go fmt solution meant to minimize
whitespace changes to the block where a code author hinted at desired
comments position."

I believe the absence of any gofmt knobs (opt-ins) is a feature that's
not going away. You can always use your private fork, if you want. But
most people will not accept code that is not formatted by the
"standard" gofmt. Because again, the uniformity is the whole point of
gofmt's existence.

-- 
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-U%3DMomr0MMZcSpt5OdajMXF97G1XqmYhm8LLKVAiLXccA%40mail.gmail.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-19 Thread Manlio Perillo
On Wednesday, February 19, 2020 at 7:26:32 PM UTC+1, ohir wrote:
>
> Dnia 2020-02-18, o godz. 10:16:57 
> Manlio Perillo > napisał(a): 
>
> > Here is an example of a diff with a lot of noise, where the actual 
> change 
> > is very hard to see: 
> > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd 
>
> > Manlio 
>
> I just posted a brief proposal — keep tabs on it, as I neither have a time 
> for, 
> nor I long for next round of defending the obvious again. 
>
> https://github.com/golang/go/issues/37299 
>
> TC, 
>
>
Thanks.  However I have to admit that is a bit complex and the cs-mark is a 
bit obtrusive.


Manlio 

-- 
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/f8b0897e-15a8-4b75-b96b-73b77af85132%40googlegroups.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-19 Thread Wojciech S. Czarnecki
Dnia 2020-02-18, o godz. 10:16:57
Manlio Perillo  napisał(a):

> Here is an example of a diff with a lot of noise, where the actual change 
> is very hard to see:
> https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd

> Manlio

I just posted a brief proposal — keep tabs on it, as I neither have a time for,
nor I long for next round of defending the obvious again.

https://github.com/golang/go/issues/37299

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200219192557.54e8cbba%40xmint.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-18 Thread David Riley
On Feb 18, 2020, at 9:15 PM, Wojciech S. Czarnecki  wrote:
> 
> [1] use marker relative to the opening brace hinting at the desired comment
> position, ie. compute type-start position relative to the opening brace then
> comment-start position relative to the marker from the comment of the brace
> line. Adjust both positions modulo 8 rounded up. Field name that gets over
> past the established type-start position stays over.

If I'm understanding what's proposed here, I think I like it.  The other option 
would be a wider fixed tab stop, but no one is ever going to agree on what that 
should be (but it worked for Fortran 77, I guess).


- Dave

-- 
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/15D2D587-2593-447D-B81B-B485F58F3255%40gmail.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-18 Thread andrey mirtchovski
?w=1 is an option.

On Tue, Feb 18, 2020 at 7:16 PM Wojciech S. Czarnecki  wrote:
>
> Dnia 2020-02-18, o godz. 10:16:57
> Manlio Perillo  napisał(a):
>
> > Here is an example of a diff with a lot of noise, where the actual change
> > is very hard to see:
> > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
> >
> > Note that using `git diff -w` is not a solution, since it can only be used
> > locally.  The full diff will be shown by github and friends.
>
> Yes. It could be easily fixed with cosmetic changes to gofmt in a way that
> is tab-width neutral [1] but I doubt it would be seriously considered given
> current NIH-driven mood of dev's hive.
>
> [1] use marker relative to the opening brace hinting at the desired comment
> position, ie. compute type-start position relative to the opening brace then
> comment-start position relative to the marker from the comment of the brace
> line. Adjust both positions modulo 8 rounded up. Field name that gets over
> past the established type-start position stays over.
>
> Done.
>
> Everything, except overlong names, lines up on the screen with ts=2, ts=3, 
> ts=4
> as well as with ts=8. Changesets contain no whitespace changes, because there
> is no such gofmt introduced changes anymore — ofc unless you change type
> identifier past the rounded 8 boundary. Then whole struct will make to the
> changeset, not just huge parts of it.
>
> Hope this helps,
>
> > Manlio
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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/20200219031558.77411fc7%40xmint.

-- 
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/CAK4xykUszUOJYGxv2WGxUegnY6eHR-tEcYbgqMkLJiXBknxx0w%40mail.gmail.com.


Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

2020-02-18 Thread Wojciech S. Czarnecki
Dnia 2020-02-18, o godz. 10:16:57
Manlio Perillo  napisał(a):

> Here is an example of a diff with a lot of noise, where the actual change 
> is very hard to see:
> https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd
> 
> Note that using `git diff -w` is not a solution, since it can only be used 
> locally.  The full diff will be shown by github and friends.

Yes. It could be easily fixed with cosmetic changes to gofmt in a way that
is tab-width neutral [1] but I doubt it would be seriously considered given
current NIH-driven mood of dev's hive.

[1] use marker relative to the opening brace hinting at the desired comment
position, ie. compute type-start position relative to the opening brace then
comment-start position relative to the marker from the comment of the brace
line. Adjust both positions modulo 8 rounded up. Field name that gets over
past the established type-start position stays over.

Done. 

Everything, except overlong names, lines up on the screen with ts=2, ts=3, ts=4 
as well as with ts=8. Changesets contain no whitespace changes, because there
is no such gofmt introduced changes anymore — ofc unless you change type
identifier past the rounded 8 boundary. Then whole struct will make to the
changeset, not just huge parts of it.

Hope this helps,

> Manlio

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20200219031558.77411fc7%40xmint.