huh TIL...
Thanks, I now see that there's no problem with the type inference.
On Wednesday, 22 December 2021 at 4:48:02 pm UTC+11 Ian Lance Taylor wrote:
> On Tue, Dec 21, 2021 at 9:42 PM Corin Lawson wrote:
> >
> > I'm new here, but write Go on a daily basis for fun and profit. The
> other
On Tue, Dec 21, 2021 at 9:42 PM Corin Lawson wrote:
>
> I'm new here, but write Go on a daily basis for fun and profit. The other
> day I wrote a giant type switch that was intended to organise a bag of
> various things into various bags each containing things of a single concrete
> type.
Hi!
I'm new here, but write Go on a daily basis for fun and profit. The other
day I wrote a giant type switch that was intended to organise a bag of
various things into various bags each containing things of a single
concrete type. For example: https://go.dev/play/p/fqYXEP2YG_9 (Note that
On Tue, Dec 21, 2021 at 10:14 AM Mitar wrote:
>
> I am trying to make a CLI tool which would have sub-commands and some
> of them would call into other existing CLI tools (written in Go). The
> issue is that those other commands sometimes have CLI parsing code as
> part of the main package (e.g.,
Hi!
I am trying to make a CLI tool which would have sub-commands and some
of them would call into other existing CLI tools (written in Go). The
issue is that those other commands sometimes have CLI parsing code as
part of the main package (e.g., example.com/cmd/example) and the hook
to call into
Hi Sean!
Thank you very much for your answer!
After trying out some other options [and calming down], I realized I could
indeed just remove the go.mod completely and still have the wiring be
functional.
For exposed constants (fortunately we didn't have exposed global
variables), I just reported
