Re: [go-nuts] Re: go get v git clone

One has to admit this is a bit of an unfortunate regression in the 'go get' workflow. Especially for 'vanity import' packages. What's the repository holding the sources for e.g. 'golang.org/x/tools' or 'gioui.org' ? It used to be really simple to fetch any 'go get'-import-able project. Now, not

Re: [go-nuts] No generic, part -2

Hello, Thank you for the answers. Now I have something to read. :-) So, sorry for my English. Personally, I would add a dynamic dispatching into GO and left language without generic in order to keep simplicity for GO and to make life of the applied programmers easier :-) What I'm looking for is

[go-nuts] Re: go get v git clone

You use git clone. Go get is for adding a dependency to a project. Also how do I delete something I go getted? > ~/go/pkg/mod is just a local cache, nothing you work in. You can clear the whole module cache with go clean -modcache -- You received this message because you are subscribed to the

Re: [go-nuts] No generic, part -2

On Fri, Mar 12, 2021 at 7:31 AM alex-coder wrote: > > Hello again, > I apologize for being so intrusive. > Where it is possible to read about the evaluations of labor and complexity for > GO itself for different implementations to introduce generic in GO ? LIke others, I'm not quite sure what you

[go-nuts] go get v git clone

if I want to get a git repo of go module code and start hacking on it do I use go get or git clone? I tried go get, but it downloaded to ~/go/pkg/mod and when I tried to run one of the tests it didn't work. Also there's no .git dir with the history in the go get tree of the code. Is there a way

Re: [go-nuts] Auto Make a named return map

On Sat, Mar 13, 2021 at 12:01 AM Kevin Chadwick wrote: > I do not need to understand the difficulties that exist, though I struggle > to understand the zero bytes property as surely even an empty string has a > 4 or 8 byte pointer. > A string is effectively a struct{ data *byte len int }

Re: [go-nuts] Auto Make a named return map

>This sounds like if you are suggesting to make the zero value of a map >an >empty map, which is different from initializing a map variable to an >empty >map if it a named return. That suggestion has come up a lot, both on >this >list and on the github issue tracker. It's, unfortunately, not as e

Re: [go-nuts] No generic, part -2

I would also add that there was an old generics design draft based around contracts [1] that was not accepted for multiple reasons, but one was that it wasn't clear how the implementation could actually work. This suggests that implementation issues are definitely considered during the proposal pro

Re: [go-nuts] No generic, part -2

The title of your message seems to indicate that you are looking for arguments not to implement generics. You should be aware that the proposal to add generics has been accepted , so the discussion of whether or not Go will get gener

[go-nuts] io/fs: {mount,overlay}fs

hi there, I am looking for an io/fs.FS-based package that can "mount" a provided io/fs.FS filesystem under some directory on some other io/fs.FS. ie: more or less the io/fs equivalent of: $> mount /dev/sd4 /mnt/sub/dir subtree := os.DirFS("/path/to/some/dir") _, _ = subtree.Open("file1.txt") //

[go-nuts] No generic, part -2

Hello again, I apologize for being so intrusive. Where it is possible to read about the evaluations of labor and complexity for GO itself for different implementations to introduce generic in GO ? Thank you. -- You received this message because you are subscribed to the Google Groups "golan

[go-nuts] Re: [ANN] New german translations

"Kode" really seems nonstandard to me. It really pops out. I'd definitely spell it "Code" in German and even then it seems like colloquial usage. I'd prefer Quellcode or Quelltext or Programm. "Kode aus einem externen Paket rufen" should really be "aufrufen" no matter how you feel about "Kode"

Re: [go-nuts] struct conversion, new fields, and incompatibility

I don’t think you can separate the two - it seems the OP purpose of using the struct conversion is to facilitate a different serialization format. This is a place where Gos convenience (struct tags) is running into explicitness. The struct conversion is nothing more than a magic copy. Make this

Re: [go-nuts] Auto Make a named return map

On 3/12/21 12:33 PM, Axel Wagner wrote: > This sounds like if you are suggesting to make the zero value of a map an > empty > map, which is different from initializing a map variable to an empty map if > it a > named return. That suggestion has come up a lot, both on this list and on the > github

Re: [go-nuts] Auto Make a named return map

On Fri, Mar 12, 2021 at 12:51 PM Kevin Chadwick wrote: > I would argue that a string could be nil but isn't and that being 0 len is > a > good thing. Ergo, it is strange for a map to be doing premature > optimisation, > when you could test it for 0 size. More likely, it is an artifact of make > c

Re: [go-nuts] Auto Make a named return map

On 3/12/21 11:51 AM, Kevin Chadwick wrote: > Incidentally, I would be happy with err != "". Of course I do appreciate the wrapping/error testing. Though I use little/no more than could be accomplished with typed strings.Contains, personally. -- You received this message because you are subscribe

Re: [go-nuts] struct conversion, new fields, and incompatibility

On Fri, Mar 12, 2021 at 10:16 AM Brian Candler wrote: > I can see two separate things under discussion - compatibility of struct > types for conversion, and backwards-compatibility of serialization [JSON? > Protobuf?] > Backwards-compatibility of serialization is a red herring. It is off-topic a

[go-nuts] Re: Unexpected error from os.DirEntry on Win10

On Thursday, 11 March 2021 at 20:31:24 UTC rob wrote: > As the subject line says, this is on windows. > I'm getting the file not found error for every file returned by the glob > function. > > I guess I misunderstood the purpose of ReadDir, and I really need to call > os.Lstat to retrieve the

Re: [go-nuts] Auto Make a named return map

On 3/12/21 7:16 AM, Axel Wagner wrote: > I find named returns produce more readable code but I avoid them when > returning a map. > > > Personally, I would recommend avoiding naked returns in all cases. In the best > case, a naked return is less explicit and requires readers to think abou

Re: [go-nuts] Why this global variable assignment is deleted in the infinite loop?

I am grateful for your apply. The code came from an article introducing go memory model and we tested it and tried to understand the cause just because of curiosity. Thanks the buggy code since now we totally understand when and how to deal with concurrency in Go more. 在2021年3月12日星期五 UTC+8 下午3:

Re: [go-nuts] struct conversion, new fields, and incompatibility

I think it's clear that *any* change to an interface - including adding or removing methods, or changing the arguments or return types of any method - must be a breaking change. - *Adding* a method to an interface means that a concrete type which implemented the interface before, won't satisfy

Re: [go-nuts] struct conversion, new fields, and incompatibility

> Hence breakage seems entirely reasonable to me, to force the user of T1 to decide how to handle it. This feels like saying, if a customer implements an interface and that interface adds a method, it is up to the user to decide how to handle it. There is even a suggestion to use private method l

Re: [go-nuts] struct conversion, new fields, and incompatibility

Maybe the argument goes something like this: * package P exports a struct type T1 * package Q deals with values of type T1 * package Q wants to serialize objects of type T1, but T1 doesn't have the desired set of tags; so it defines a new type T2 which is the same as T1 but with different tags *

Re: [go-nuts] struct conversion, new fields, and incompatibility

My apologies this is already called out in apidiff's desiderata section under the Using an Identical Type Externally heading. https://pkg.go.dev/golang.org/x/exp/apidiff This means that it is already apocrypha. Is there still discussion to be had about struct tags and marshaling, or should I open

Re: [go-nuts] struct conversion, new fields, and incompatibility

On Friday, 12 March 2021 at 06:56:46 UTC axel.wa...@googlemail.com wrote: > On Fri, Mar 12, 2021 at 3:26 AM Robert Engels > wrote: > >> I must be dense on this. I have no idea why there is any use of struct >> tags or JSON marshaling in the sample code. >> > > To demonstrate why converting betw

Re: [go-nuts] struct conversion, new fields, and incompatibility

Nobody seems in favour of making this a "technically" breaking change, like changing the value of a string constant, though I think there is an argument. Does it seem reasonable to add a vet lint for this type of struct type conversion? Or is more discussion warranted? I am looking to eventually d