[go-nuts] command to pre-compile vendor libs

Hi, in both my Nix and Docker builds I have a step to build all libraries in /vendor, and then cache that. Works great, saves me multiple minutes for every CI build. Now I would like to improve the command, this is what I currently use: $ go build -v `cat vendor/modules.txt |grep -v '#'|grep -v

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

Then that type probably won't work with encoding/asn1. If you have control over the call to asn1.Marshal, you could always create a "data transfer object " to translate between this third-party type and a type that you control that has a struc

Re: [go-nuts] tuples! tuples! tuples!

*> FWIW this kind of restriction has no precedent in Go. Currently any type may be unnamed. This restriction seems arbitrary and irregular to me. * It seems unpopular. *> Isn't this illegal according to your TupleType syntax above? * Further evidence of a wrong idea :) *>> [T (any, any)] de

Re: [go-nuts] encoding/asn1 I can't Marshal a struct with pointer members

Thank you very much for your answer, but I cannot modify the definition of the field because this is the structure of the third-party library. On Monday, April 29, 2024 at 1:01:18 AM UTC+8 Def Ceb wrote: > Most marshal/unmarshal functions are unwilling to marshal/unmarshal > structs with pointer

Re: [go-nuts] tuples! tuples! tuples!

On Sun, 28 Apr 2024 at 12:10, Andrew Harris wrote: > Bouncing out from some recent discussions on the github issue tracker, it > seems like there's some interest in tuples in Go. I thought the discussion > in #66651 led to some interesting ideas, but it's also beginning to drift. > Maybe this is

Re: [go-nuts] tuples! tuples! tuples!

Brian: 1: There would be no access to implicitly typed tuple elements. Both implicit and named tuple values would expand with `...`, for example in an assignment like `x, y := (0, 0)...`. (FWIW, #64457 suggested decimal names for tuple elements `.0`, `.1` etc.) 2: #64457 and #66651 revealed so