[go-nuts] Re: How to install protoc-gen-go (Go protocol buffer compiler plugin) in windows ?

[Joseph Hoeller]

How do you do this on Windows?

On Thursday, June 25, 2015 at 9:20:02 AM UTC-4 Joshua wrote:

> I use both. Did you include the %GOPATH%/bin in your %PATH%?
>
> Joshua
>
>
> On Thursday, June 25, 2015 at 9:17:51 AM UTC-4, Aravinth Veeramuthu wrote:
>>
>> Yes, I download it.But i have some problem to run the command and it 
>> shows --go_out protoc-gen-go : The system cannot find the file specified.
>> Are u the Windows user or Linux user?
>>
>> On Thursday, June 25, 2015 at 4:59:46 PM UTC+5:30, Joshua wrote:
>>>
>>> Did you download protoc? protoc uses the protoc-gen-go as a plugin. I 
>>> usually just use something like this:
>>>protoc --go_out=. *.proto
>>>
>>> Joshua
>>>
>>> On Thursday, June 25, 2015 at 5:02:43 AM UTC-4, Aravinth Veeramuthu 
>>> wrote:

 How to install protoc-gen-go (Go protocol buffer compiler plugin) in 
 windows ?

 I have a problem when i convert the *.proto type protocol buffer file 
 into the *.pb.go format using protoc-gen-go Complier.

 I got the following error...

 -go_out: protoc-gen-go: The system cannot find the file specified.

>>>

-- 
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/952e6a82-097f-4304-8c23-45c53b897ad1n%40googlegroups.com.

[go-nuts] 00% remote Job Opportunity

[Victoria Bernal]

Dear Go Developers in Latin America, 

We have an opportunity to work 100% Remote with an american company. For 
more details about the requirements please visit: 
https://apply.workable.com/zipdev/j/A8762516D1/

   - 4+ years as a software engineering experience
   - 3+ years with a scripting languages like Go, Scala, Ruby or Python
   - Experience working with UI technologies
   - 2+ years of experience in building microservices

For more info send me an email: victoria.ber...@zipdev.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/98b8c996-286c-4418-bd18-db8dd129eff2n%40googlegroups.com.

Re: [go-nuts] No Generics - Type Binding on Imports

[Ian Lance Taylor]

On Mon, Mar 22, 2021 at 2:10 AM Martin Leiser  wrote:
>
> > What happens if
> >I try to import a package that defines that Min function but I set the
> >argument type to some that does not support the < operator?
> I would simply write two similar packages: one using the above mentioned 
> enumerated interface of the accepted draft,
> and another using the
> type Lesser interface {Less(Lesser) Lesser }
> The implementation of min with Lesser:
>func Min(a, b Lesser) Lesser { if a.Less(b) {return a;} else {return b;}}
> The implementation of Min with "ComparableStdType" stolen from the accepted 
> draft:
>func Min(a, b ComparableStdType) ComparableStdType {if a < b {return a; } 
> else {return b;}

Sorry, I didn't phrase my question well.  I wasn't asking how I can
handle that case.  I was asking how the compiler detects an erroneous
use of the Min function with a type that does not support the <
operator.

But I gather that you are suggesting that we use type lists as in the
current generics proposal, so that answers that question.

If we do that, it seems to me that your proposal is no simpler than
the current generics proposal.  And I think that in practice it will
be somewhat harder to use, because it ties generic type scope closely
to package scope.  I don't think it's the case that all generic types
are logically tied to a package.  Forcing them to be associated with
packages will force people to break up their programs in unnatural
ways in order to use generic types.

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/CAOyqgcW-xt__atkt6R%3DmjagXbCRu0pQcMKZ6gfJNxKNwgFXSCg%40mail.gmail.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Ian Lance Taylor]

On Mon, Mar 22, 2021 at 7:40 AM Alex  wrote:
>
> A package you import could be using cgo, you don't have to be using it 
> directly.

I'll add that I think that this must be what is happening, as you
could not get that error message in a program that doesn't use cgo
anywhere.

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/CAOyqgcUHRb7czF2m%3DfknGvtVROXbDUfYbeZVMKP_pK%3D8NWvurw%40mail.gmail.com.

Re: [go-nuts] Trying to use a tool in my build (a friction log)

['Jay Conrod' via golang-nuts]

> Is it by design that these two commands ['go mod tidy' and 'go mod
vendor'] are unstable like that?

That is more or less by design, but the behavior has evolved over time and
it may be worth revisiting.

This was discussed in #29058 .
The rationale was that because 'go mod vendor' deletes and rebuilds the
entire vendor directory, it would be dangerous to do that implicitly inside
another command like 'go mod tidy', since people frequently make local
changes to vendor, like when preparing a patch for upstream.

That discussion was a couple years ago, before vendoring was enabled
automatically. At the time, you had to specify -mod=vendor with build
commands.

A better user experience might be 1) support for incremental changes to the
vendor directory via 'go get', 'go mod tidy', 2) detection of local changes
to the vendor directory so we can avoid overwriting them.

I've opened #45161  to restart
that discussion.

> This tool in particular seems to try to read a DB file from a subdir of
the directory its source code came from (as per `runtime.Caller(0)`) which
...doesn't work at all with vendoring, since the dir doesn't contain Go
code.

> AFAIK there's not a way to ask `go mod vendor` to include the whole repo
is there?  I can't find a spec for modules.txt - it would be super cool if
I could add some tag in there...  As it stands, all this was for naught.

Is there another way to include and locate that file? Even if it were
vendored, runtime.Caller(0) may be unreliable when -trimpath is used, and
the files will be read-only in the module cache when vendoring is not used.

'go mod vendor' only pulls in directories for packages needed to build
packages in the main module and their tests ('go list -test -deps ./...',
essentially). I don't think we even include testdata or packages imported
by those packages' tests.

We don't have a spec for vendor/modules.txt. it basically contains enough
information for the go command to know which packages are vendored and
which modules they came from.

On Sat, Mar 20, 2021 at 12:47 PM Manlio Perillo 
wrote:

> Il giorno venerdì 19 marzo 2021 alle 23:20:49 UTC+1 Tim Hockin ha scritto:
>
>> Thanks for feedback, comments below
>>
>> On Thu, Mar 18, 2021 at 3:35 PM Jay Conrod  wrote:
>>
>>>
>>> > [...]
>
>>
>>
>>> *2. "writing go.mod cache" error messages*
>>>
>>> This error message should be a lot better. Sorry about that.
>>>
>>
>> I mean, "mkdir /home/thockin/go: not a directory" is pretty concise -
>> it's not a directory (on purpose) because I really don't want Go randomly
>> deciding to write stuff to my homedir (which I suspected was happening, and
>> that's why I made it a non-directory :)
>>
>>
>
> If you don't want the go tool to write files to your home directory, you
> can just define a custom GOPATH or GOMODCACHE.  As an example, on my
> sysytem I have set GOPATH to ~/.local/lib/go, and this directory is
> excluded from the backup.
>
> 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/8002edf8-1a9e-44a6-a427-3fbc2b4e1dc1n%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/CAGCADbYLzKJi7AYdgzyJmm4WHHe4GWgQ%3DseFfxLPOLmpL5Bg3w%40mail.gmail.com.

[go-nuts] golang/mobile: Could we add GitHub Actions for PRs?

[Michael Chong]

GitHub Actions  has been introduced 
for a while.

For PRs of go-mobile , only *google-cla 
*is running on GitHub Actions.
I wonder whether we can add support like automatic testing?


-- 
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/e6194e76-bd34-40d0-995e-dff5110b98afn%40googlegroups.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Alex]

A package you import could be using cgo, you don't have to be using it 
directly.
If you run `GOOS=linux go build` on a mac, that is cross compileing and cgo 
is disabled by default.
You can try `CGO_ENABLED=0 go build` and if it works then it is cgo related.

>From the error messages, it looks like a package for using a SMC or other 
hardware.
On Monday, 22 March 2021 at 9:02:36 pm UTC+8 max...@gmail.com wrote:

> But I didn't write cgo code in my project. 
> The weird part is I can build success with *GOOS=linux go build*, but 
> failed with *GOOS=darwin go build*
>
> On Friday, March 19, 2021 at 5:11:57 AM UTC+8 Ian Lance Taylor wrote:
>
>> On Thu, Mar 18, 2021 at 9:55 AM Max Xu  wrote:
>> >
>> > I'm running into a weird bug:
>> >
>> > Failed with command:
>> > GOOS=darwin go build
>> >
>> > Bug success with:
>> > GOOS=linux go build
>> >
>> > The failed Message:
>> >
>> > /usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang 
>> failed: exit status 1
>> > duplicate symbol '_readdrivestat' in:
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
>> > duplicate symbol '_get_temperature' in:
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
>> > duplicate symbol '_open_smc' in:
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
>> > duplicate symbol '_close_smc' in:
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
>> > 
>> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
>> > ld: 4 duplicate symbols for architecture x86_64
>> > clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>>
>> Hard to say without seeing the code, but my first guess would be
>> erroneous cgo code. It looks like you have multiple cases of cgo code
>> that are defining the same symbol in the C preamble without declaring
>> it as `static`.
>>
>> 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/effcc88f-2465-4877-a237-451ed4271f48n%40googlegroups.com.

Re: [go-nuts] go build error in darwin: duplicate symbol

[Max Xu]

But I didn't write cgo code in my project. 
The weird part is I can build success with *GOOS=linux go build*, but 
failed with *GOOS=darwin go build*

On Friday, March 19, 2021 at 5:11:57 AM UTC+8 Ian Lance Taylor wrote:

> On Thu, Mar 18, 2021 at 9:55 AM Max Xu  wrote:
> >
> > I'm running into a weird bug:
> >
> > Failed with command:
> > GOOS=darwin go build
> >
> > Bug success with:
> > GOOS=linux go build
> >
> > The failed Message:
> >
> > /usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang 
> failed: exit status 1
> > duplicate symbol '_readdrivestat' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/11.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/36.o
> > duplicate symbol '_get_temperature' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > duplicate symbol '_open_smc' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > duplicate symbol '_close_smc' in:
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/14.o
> > 
> /var/folders/tx/5c8vkq6x2k1f5nqvbj271qycgn/T/go-link-162098608/39.o
> > ld: 4 duplicate symbols for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> Hard to say without seeing the code, but my first guess would be
> erroneous cgo code. It looks like you have multiple cases of cgo code
> that are defining the same symbol in the C preamble without declaring
> it as `static`.
>
> 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/f9ac679f-09f5-44c1-826f-387b2adf2e7fn%40googlegroups.com.

Re: [go-nuts] No Generics - Type Binding on Imports

[Martin Leiser]

Am 22.03.2021 um 10:10 schrieb Martin Leiser:


Am 21. März 2021 22:01:38 MEZ schrieb Ian Lance Taylor :

On Sun, Mar 21, 2021 at 1:02 PM Martin Leiser 
wrote:

...


 import "container/list" stringlist type ElementType = string

What if I want to have a list of lists of strings?

That is a no brainer. The type "list of strings" in the example is: 
"stringlist.Element". So you add the following line:
import "container/list" liststringlist type ElementType = stringlist.Element


The really tricky question is in my opinion:
What if the binding type is a parameter type itself?

    type MyElement interface{ String() string }

and this is bound to

    import "container/list" myelementlist type ElementType = MyElement

I.e my container type build on the list type for its implementation.
This really adds complexity to the implementation, because every import 
binding "MyElement" also binds the list package parameter type.



What if I want to have a list of some unexported type that I defined
in this package?

That is the "Complicated" part of the proposal. It can be solved and it is not 
that tricky:
- All the compiler really needs to know about the bound type is specified by 
the bound interface type, plus the storage size.
- You have to outrule cyclic definitions, but they are impossible, because it 
is the implementaion which introduces the cycle.
- You may even fall back to the normal implementation of "interface types" 
behind the scenes when appropriate.

Semantically all is solved by the following three program transformations 
chained together:
1. Make the private Type exported (does not change behaviour as long as you 
avoid name clashes by consistent renaming)
2. Add an import to the Package defining the binding type in a renamed copy of 
the generic package
3. replace the definition of the bind type by a type alias with the binding 
type in the copy of step 2


So steps 2 and 3 have to take place in the proper order and recursively 
across separate packages in case of parameter types used as binding types.


Every binding of "MyElement" type adds another binding to list.ElementType.
Complicated but solvable, but perhaps only if cyclic imports our 
outruled for type binding imports in the first place.



Thanks again.

Ian

Thanks for your quick response.

Martin


Martin

--
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/26262f4f-41ad-3b4c-5682-17946174cc3a%40gmail.com.

[go-nuts] net.Listen is unable to detect port conflict on Windows

[Nicola Murino]

Hi,

I recently discovered this strange behaviour, Windows allows the 
coexistence of three types of sockets on the same transport-layer service 
port, for example, 127.0.0.1:8080, [::1]:8080 and [:::0.0.0.0]:8080.

So if you use something like:

net.Listen("tcp", fmt.Sprintf(":%d", port)

and another program already uses the same port using an IPv4 address, 
Listen will not fail.

If instead you use:

net.Listen("tcp4", fmt.Sprintf(":%d", port)

it will fail as expected.

Based on the following issues, this is the intended behaviour 

https://github.com/golang/go/issues/45150
https://github.com/golang/go/issues/30291

so a Go listener behaves differently based on the operating system and this 
could cause unexpected bug reports from Windows users.

In my program I want to listen on both IPv4 and IPv6 (if available) and so 
I use "tcp" as address.

To be able to detect port conflict with other programs, I have to do 
something like this:

if runtime.GOOS != osWindows {
return
}
listener, err := net.Listen("tcp4", fmt.Sprintf(":%d", port))
if err != nil {
os.Exit(1)
}
listener.Close()

before starting net.Listen with "tcp" address.

So all of you use a similar fix? Do you know a cleaner solution? 

I would have expected such a workaround within Go itself if it is the only 
way.

Based on the above issues, python had the same problem in the past but it 
seems now fixed in recent versions.

Thank you
Nicola

-- 
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/cf310370-eaea-45a8-bf13-1a8bbc919fc4n%40googlegroups.com.

[go-nuts] Re: Fixing deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer does anything; use contexts

[cpu...@gmail.com]

Opened https://github.com/golang/oauth2/issues/487 to propose removing the 
`CancelRequest` method.

Cheers,
Andreas

On Friday, March 19, 2021 at 5:44:21 PM UTC+1 cpu...@gmail.com wrote:

> Hi all,
>
> I've recently learned about oauth2 and started to convert some of my 
> "manual" code using net/http to use an  underlying oauth2.Transport for 
> executing authenticated requests and token refresh.
>
> As a result, my application now sometimes shows 
>
> deprecated: golang.org/x/oauth2: Transport.CancelRequest no longer 
> does anything; use contexts
>
> Of course, I'm nowhere calling that method. Digging into the default HTTP 
> Client (
> https://github.com/golang/go/blob/a937729c2c2f6950a32bc5cd0f5b88700882f078/src/net/http/client.go)
>  
> reads:
>
> // For compatibility, the Client will also use the deprecated
> // CancelRequest method on Transport if found. New
> // RoundTripper implementations should use the Request's Context
> // for cancellation instead of implementing CancelRequest.
> Timeout time.Duration
>
> I would read this as: if you have an http.Client with an underlying 
> oauth2.Transport and the request times out, the oauth2.Transport's 
> CancelRequest method will *always* be called and hence show the undesired 
> warning.
>
> Is that correct?
>
> Thanks,
> Andreas
>

-- 
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/76840e3d-f555-4be1-baa7-78aa2f98d1d8n%40googlegroups.com.

Re: [go-nuts] No Generics - Type Binding on Imports

[Martin Leiser]

Am 21. März 2021 22:01:38 MEZ schrieb Ian Lance Taylor :
>On Sun, Mar 21, 2021 at 1:02 PM Martin Leiser 
>wrote:
>>
>> I think so. But How? Remember we need to do two things:
>>
>> - A way to define type parameters.
>>
>> - A way to bind the type parameters to concrete types at compile
>time
>
>Thanks for the note.
>
>I think that a generics proposal needs to do three things.  The third
>is that it needs to describe which operations are permitted for a type
>parameter.
Absolutely correct.
Especially if you think about the kind of things you may do with type 
parameters and type inference in languages like Haskell or ML.
The only thing you aktually want to do with binding types of type parameters 
is: use them as parameters of your package.
No difference to the accepted proposal here.
The key difference here is the way to define and bind the parameters.
All else should be as equal as possible, because the accepted proposal is good.
>
>
>> But after we named it "ElementType" we can get a hold of it and bind
>it in the package we intend to use e.G. a "list of strings":
>>
>> import "container/list"  type ElementType string
>
>This general kind of idea has been suggested quite a few times before.
>Here are a few examples:
>
>https://gist.github.com/PeterRK/41d4d3f54b8db55cd616403fd5a389f3
>https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/blob/master/use-package-as-gen.md
>https://groups.google.com/g/golang-nuts/c/xKYXZpsWHus/m/SS4FKMBEAQAJ
>
>There are others.
>
yes I know about eg. even older ones like genny 
https://github.com/cheekybits/genny
>
>> Last features. If you need two different bindings in one package, say
>a list of string and a list of int you may use:
>>
>> import "container/list" intlist  type ElementType = int
>>
>> import "container/list" stringlist type ElementType = string
>
>What if I want to have a list of lists of strings?
That is a no brainer. The type "list of strings" in the example is: 
"stringlist.Element". So you add the following line:
   import "container/list" liststringlist type ElementType = stringlist.Element
>
>What if I want to have a list of some unexported type that I defined
>in this package?
That is the "Complicated" part of the proposal. It can be solved and it is not 
that tricky:
- All the compiler really needs to know about the bound type is specified by 
the bound interface type, plus the storage size.
- You have to outrule cyclic definitions, but they are impossible, because it 
is the implementaion which introduces the cycle.
- You may even fall back to the normal implementation of "interface types" 
behind the scenes when appropriate.

Semantically all is solved by the following three program transformations 
chained together:
1. Make the private Type exported (does not change behaviour as long as you 
avoid name clashes by consistent renaming)
2. Add an import to the Package defining the binding type in a renamed copy of 
the generic package
3. replace the definition of the bind type by a type alias with the binding 
type in the copy of step 2
In my posting I only named the 3. transformation to keep things simple.
Steps 2 and 3 have to be done at most once for any binding type in the whole 
program.
All this may be implemented as "source to source" transformations,
as you may know from the compiler construction class talking about generics
(mine was >30 years age full of examples from LIS and Ada, I am a bit rusty 
here).
And it gets way more complicated when you actually start to do it in reality.
But it is this simple to describe here, because I choose to bind on the package 
level.
That is part of the trick. The price are global variables.

But can You always apply this transformation? Are there additional limitations 
required? I do not know yet.
I believe you must outrule a import cycle for the type binding import. Which 
should be of no practical impact.

>  That seems to require interweaving type definitions
>and imports in ways that the language does not currently support.
Hmm, do not think so, see above. The result of the program transformation above 
should be a valid Go 1 program.

For every type binding you have to have a way to "instantiate" a copy of the 
whole package with this binding.
And the "stringlist" must only have one instantiation for all packages using 
the same type binding imports.
Doing this efficient and effective, that is the complicated part.

Did I mention that there is no big difference in complexity in the 
implementation of my proposal and the accepted one?
Sorry for ommiting that.
I actually see an additional risk, when talking about global variables 
involving the parameter types.
(Which makes no sense for practical use, but has to be covered or outruled.)

>
>With this proposal, how can I write a min function that works for any
>integer type, including a user-defined integer type?  
No. I did not include user-defined types. Buf if You add the enumerated 
interface types of the