Re: [go-nuts] GO111MODULE=off go get deprecated?

[Jeffery Carr]

On Monday, March 4, 2024 at 8:44:14 AM UTC-6 Bryan C. Mills wrote:

Per https://go.dev/doc/go1.22#go-command:
> go get is no longer supported outside of a module in the legacy GOPATH mode 
(that is, with GO111MODULE=off). Other build commands, such as go build and go 
test, will continue to work indefinitely for legacy GOPATH programs.

This was discussed in https://go.dev/issue/60915, which simultaneously 
proposed to preserve `go build` and `go test` and to finish removing `go 
get` in GOPATH mode. (That proposal was a change to the plan stated in 
https://go.dev/blog/go116-module-changes, which said: “We plan to drop 
support for GOPATH mode in Go 1.17.” That clearly did not happen as planned 
in Go 1.17.)


Thank you for the helpful link to 60915.

GO111MODULE=off go get  I used because it was a very easy 
way to git clone my programs and all the packages in the correct go import 
paths.

If my go.work file is:
go 1.22.0

use (
mygit.test.org/apps/myapp
mygit.test.org/lib/myapppackage1
myothergitserver.org/lib/myotherfunthing2
friendsproject.org/someotherpackage3
)

How do I git clone the repos? I just don't seem to understand what I'm 
supposed to do. 

I made the go path mapping to the git clone paths, so obviously I can write 
something to do this, but using 'go get' before to do the git clone was 
really easy! Especially since it got all the dependencies also.

Again, thanks for the help,
jcarr

BTW,
go list -json -m go.uber.org/zap@latest

@latest doesn't show the URL so one can't really get the current URL sent 
from the go-import/go-source lines.  Actually, it doesn't seem like "go 
list" hits the external authoritative server at all and maybe only looks at 
the local ~/go/pkg/ files.
 

The simplest way to download Go dependencies for code review and debugging 
is to run `go mod vendor` in your module or (newly added) `go work vendor` 
in your workspace. Also note that `go mod download -json` and `go list -m 
-json` now include origin information in most cases:

~$ go list -json -m go.uber.org/z...@v1.27.0 

...

 

"VCS": "git",
"URL": "https://github.com/uber-go/zap;,



-- 
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/17d6e3dd-4687-4474-b2cd-f44aa702f436n%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Mike Schinkel]

> On Mar 4, 2024, at 5:14 PM, Ian Lance Taylor  wrote:
>> P.S. Seems to me that #4 might be the simplest way forward as it would allow 
>> for creation of types that cannot be represented as their literal subtype 
>> value to pass as a parameter to a `func`, and it would not require any new 
>> keywords or concepts added to Go the language, or at least I don't think it 
>> would?
>> 
>> Is there any reason Go could not relax the allowable values for const to be 
>> able to support constructs that can be determined at runtime such as `const 
>> April = [1]byte{4}`?
> 
> I think this is https://go.dev/issue/6386.

Thank you Ian for acknowledging, and for the link, and yes that issue does 
cover it.

However, that issue is a general superset whereas I was proposed a very 
constraint language enhancement.

In that issue it seems the pushback was:

1. It is unclear where to draw the line on what to allow because of all the 
ramifications, and 

2. "Nice to have" is not sufficient reason to add a feature to the language.

> The simple version only works if the variable
> can be declared and initialized in the same statement.  That isn't
> alway feasible, which is why init functions exist.  It absolutely
> prohibits circular data structures, which could be limiting. 

Those are definitely challenging concerns when considering the larger ask for 
the proposal in issue 6386.

However, to address the enum use-case maybe a much smaller subset proposal 
could suffice, one that can be declared and initialized in the same statement 
and that has no need for circular data structures.  

One that could also address both of those aforementioned criticisms:

1. The subset to include would only be those things that would be needed to 
address the enum use-case, which I think would be fixed-sized arrays and 
structs (and not maps nor slices I previously pondered.) 

Those should be able to contain only other constants, which I think would 
include contained fixed-sized arrays and structs, but nothing with a pointer 
and attempting to take the address of any of those constants should throw a 
compiler error.

2. This proposal would not be because it is "nice to have" but instead it would 
enable a developer to create function whose parameters could only be satisfied 
by one of the values of a type used for enums as specified by the developer.  
IOW, it solves a legitimate development concern and is not just a nice-to-have.

The only real downside I can see is if implementing this would someone paint 
the language in a corner so that it could not be enhanced in a better way in 
the future. Maybe my vision is too limited, but that doesn't seem likely with 
such a small, backward compatible change that introduces nothing new other than 
relaxing an existing constraint.

Certainly some people would say "Well if you are going to do that, why not do 
the entirety of 6386?" And if one of my hot buttons required arbitrary types to 
be assigned to a const, I might be one of those people too. But the Go team 
seems to be particularly adept at saying "We are doing this because we have a 
specific reason, and today, we are only doing this. Maybe we'll do more in the 
future, but not today." Maybe that could allow improves enums in the next 
version of Go without having to eat the elephant all at once?

Here I modified is Brian Candler's example to be what I envision could address 
the enum use-case:

1. Non-pointer instances of `struct` and `[...]array` are assignable to a 
`const`, and 
2. Casting a literal to a `struct` `[...]array` type would instantiate the type 
and assign the literal's value to the first element or property.

https://goplay.tools/snippet/xuGipbUVlKz 


Maybe this is a sufficiently small proposal to address this valid use-case that 
the Go team could get behind it?

-Mike


-- 
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/9434DAAB-C203-43C0-A4E3-C0B5BDA0DD77%40newclarity.net.

Re: [go-nuts] text template range over Rangefunc

[Ajay Kidave]

Sure, created a proposal at https://github.com/golang/go/issues/66107

Ajay
On Monday, March 4, 2024 at 2:11:59 PM UTC-8 Ian Lance Taylor wrote:

> On Mon, Mar 4, 2024 at 11:47 AM Ajay Kidave  wrote:
> >
> > The https://go.dev/wiki/RangefuncExperiment change will be a great 
> addition to the language. I wanted to know whether the text/html template 
> std libraries will allow range over rangefunc. Currently, the doc for 
> text/template says
> >
> > {{range pipeline}} T1 {{end}}
> > The value of the pipeline must be an array, slice, map, or channel
> >
> > It would be great if rangefunc is supported in templates. The specific 
> use case for me is passing a rangefunc created on a sql row iterator to a 
> template.
>
> Makes sense to me. Do you want to open a proposal at
> https://go.dev/issue to add this to the template package? Thanks.
>
> 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/a02d1b91-d5e0-4577-946c-d1c413ce54adn%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Ian Lance Taylor]

On Mon, Mar 4, 2024 at 11:32 AM Mike Schinkel  wrote:
>

...

> 4. Relax the allowable values that can be assigned to a `const` to include 
> values that can be fully determined at compile time such as `const April = 
> [1]byte{4}` thus allowing `const` and
> types of subtypes `struct`, `map`,  array, and/or slices to be used as 
> pseudo-enums.

...

> P.S. Seems to me that #4 might be the simplest way forward as it would allow 
> for creation of types that cannot be represented as their literal subtype 
> value to pass as a parameter to a `func`, and it would not require any new 
> keywords or concepts added to Go the language, or at least I don't think it 
> would?
>
> Is there any reason Go could not relax the allowable values for const to be 
> able to support constructs that can be determined at runtime such as `const 
> April = [1]byte{4}`?

I think this is https://go.dev/issue/6386.

There are subtleties.  The simple version only works if the variable
can be declared and initialized in the same statement.  That isn't
alway feasible, which is why init functions exist.  It absolutely
prohibits circular data structures, which could be limiting.  But
anything else requires some way to separate the declaration from the
initialization while still prohibiting the value from changing after
initialization.

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/CAOyqgcV0YnFTzCGGANTOQ-ZTXb2gAiXUnXRbH1_P%3D1Qz4hH_AQ%40mail.gmail.com.

Re: [go-nuts] text template range over Rangefunc

[Ian Lance Taylor]

On Mon, Mar 4, 2024 at 11:47 AM Ajay Kidave  wrote:
>
> The https://go.dev/wiki/RangefuncExperiment change will be a great addition 
> to the language. I wanted to know whether the text/html template std 
> libraries will allow range over rangefunc. Currently, the doc for 
> text/template says
>
> {{range pipeline}} T1 {{end}}
> The value of the pipeline must be an array, slice, map, or channel
>
> It would be great if rangefunc is supported in templates. The specific use 
> case for me is passing a rangefunc created on a sql row iterator to a 
> template.

Makes sense to me.  Do you want to open a proposal at
https://go.dev/issue to add this to the template package?  Thanks.

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/CAOyqgcXv0podNt9Qyo4RpQxyR1OFx%3DWmPpnBPjJHSfSkAOtp9g%40mail.gmail.com.

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

[Jeff Stein]

And looking through the source code on os.exec_linux I think I've also 
validated this as well:

if fd[i] == i {
// dup2(i, i) won't clear close-on-exec flag on Linux,
// probably not elsewhere either.
_, _, err1 = RawSyscall(fcntl64Syscall, uintptr(fd[i]), F_SETFD, 0)
if err1 != 0 {
goto childerror
}
continue
}


On Monday, March 4, 2024 at 1:13:08 PM UTC-7 Jeff Stein wrote:

> It appears this was in fact the issue.
>
> I added some code to print out the `FD_CLOEXEC` state. Files called via 
> *syscall.Dupe2* end up with a *FD_CLOEXEC=0* whereas anything passed via 
> *ExtraFiles* has a *FDCLOEXEC=1.*
>
> Whoever said "This is impossible" thanks - you spurred me towards a 
> wonderful discovery about what NOT to do :) 
> On Monday, March 4, 2024 at 12:03:16 PM UTC-7 Jeff Stein wrote:
>
>> I think I may have discovered the issue.
>>
>> I made a sys call to duplicate the file descriptor
>>
>> dupFd, err := syscall.Dup(int(file.Fd()))
>> if err != nil {
>> log.Printf("Error duplicating file descriptor: %v", err)
>> return 0, ""
>> }
>>
>> which likely reset the FD_CLOEXEC Flag:
>>
>> (from Advanced Programming in the Unix Environment) - section 3.12:
>>
>> *The new file descriptor returned by dup is guaranteed to be the 
>> lowest-numbered available file descriptor. With dup2, we specify the value 
>> of the new descriptor with the fd2 argument. If fd2 is already open, it is 
>> first closed. If fd equals fd2, then dup2 returns fd2 without closing it. 
>> Otherwise, the FD_CLOEXEC file descriptor flag is cleared for fd2, so 
>> that fd2 is left open if the process calls exec.*
>> Does this sound like what may have been happening?
>>
>> On Monday, March 4, 2024 at 9:04:31 AM UTC-7 Jeff Stein wrote:
>>
>>> OP here -> I'm going to put together some test apps - toss them on 
>>> GitHub and make sure I actually know what I'm talking about :) 
>>>
>>> On Friday, March 1, 2024 at 7:57:15 PM UTC-7 Ian Lance Taylor wrote:
>>>
 On Fri, Mar 1, 2024 at 6:17 PM Robert Engels  
 wrote: 
 > 
 > The could be calling fork() as in the system call - which copies all 
 file descriptors but I didn’t think Go processes could fork. 
 > 
 > Seems you would need to remap stdin and stdout in the fork to do 
 anything useful. 
 > 
 > This sounds very PHP - what goes around comes around. 

 Good point, I am assuming that the OP is using the os/exec package to 
 start up a new copy of the process. 

 A simple fork without an exec can't work in Go, or in any 
 multi-threaded program. 

 Ian 


 > > On Mar 1, 2024, at 8:01 PM, Ian Lance Taylor  
 wrote: 
 > > 
 > > On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein  
 wrote: 
 > >> 
 > >> I'm struggling to understand if I'm able to do something. 
 > >> 
 > >> 
 > >> In my very odd use case we are writing a websever that handles 
 connections via a forked process. 
 > >> 
 > >> I have a listener process that listens for TCP connections. 
 > >> 
 > >> So each net.Conn that comes in we pull off its file descriptor: 
 > >> 
 > >> fd, err := conn.(*net.TCPConn).File() 
 > >> 
 > >> duplicate that file descriptor and then fork off a process passing 
 in that file descriptor. 
 > >> 
 > >> In my forked handler I'll reconstruct the HTTP connection and "do 
 stuff". 
 > >> 
 > >> The concern I'm having is that it appears when I fork a process I 
 inherit all of the parent file descriptors so if I have say 5 incoming 
 connections and then I fork my child process technically could write to a 
 different connection. 
 > >> 
 > >> I've played around with the various options: 
 > >> 
 > >> cmd.SysProcAttr = {Setpgid: false,} 
 > >> 
 > >> and using cmd.ExtraFiles 
 > >> 
 > >> No matter what I do I seem unable to limit the sub process to ONLY 
 using the specific File Descriptor I want it to have access to. 
 > >> 
 > >> I believe this is doable in C - but I'm not sure if I can do this 
 in GoLang as-is without mods . 
 > > 
 > > What you are describing shouldn't happen. A child process should 
 only 
 > > get the file descriptors explicitly passed via the os/exec.Cmd 
 fields 
 > > Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and 
 > > version of Go, and what is showing you that all file descriptors 
 are 
 > > being passed down to the child. 
 > > 
 > > 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...@googlegroups.com. 
 > > To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%40mail.gmail.com.
  


>>>

-- 

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

[Jeff Stein]

It appears this was in fact the issue.

I added some code to print out the `FD_CLOEXEC` state. Files called via 
*syscall.Dupe2* end up with a *FD_CLOEXEC=0* whereas anything passed via 
*ExtraFiles* has a *FDCLOEXEC=1.*

Whoever said "This is impossible" thanks - you spurred me towards a 
wonderful discovery about what NOT to do :) 
On Monday, March 4, 2024 at 12:03:16 PM UTC-7 Jeff Stein wrote:

> I think I may have discovered the issue.
>
> I made a sys call to duplicate the file descriptor
>
> dupFd, err := syscall.Dup(int(file.Fd()))
> if err != nil {
> log.Printf("Error duplicating file descriptor: %v", err)
> return 0, ""
> }
>
> which likely reset the FD_CLOEXEC Flag:
>
> (from Advanced Programming in the Unix Environment) - section 3.12:
>
> *The new file descriptor returned by dup is guaranteed to be the 
> lowest-numbered available file descriptor. With dup2, we specify the value 
> of the new descriptor with the fd2 argument. If fd2 is already open, it is 
> first closed. If fd equals fd2, then dup2 returns fd2 without closing it. 
> Otherwise, the FD_CLOEXEC file descriptor flag is cleared for fd2, so 
> that fd2 is left open if the process calls exec.*
> Does this sound like what may have been happening?
>
> On Monday, March 4, 2024 at 9:04:31 AM UTC-7 Jeff Stein wrote:
>
>> OP here -> I'm going to put together some test apps - toss them on GitHub 
>> and make sure I actually know what I'm talking about :) 
>>
>> On Friday, March 1, 2024 at 7:57:15 PM UTC-7 Ian Lance Taylor wrote:
>>
>>> On Fri, Mar 1, 2024 at 6:17 PM Robert Engels  
>>> wrote: 
>>> > 
>>> > The could be calling fork() as in the system call - which copies all 
>>> file descriptors but I didn’t think Go processes could fork. 
>>> > 
>>> > Seems you would need to remap stdin and stdout in the fork to do 
>>> anything useful. 
>>> > 
>>> > This sounds very PHP - what goes around comes around. 
>>>
>>> Good point, I am assuming that the OP is using the os/exec package to 
>>> start up a new copy of the process. 
>>>
>>> A simple fork without an exec can't work in Go, or in any 
>>> multi-threaded program. 
>>>
>>> Ian 
>>>
>>>
>>> > > On Mar 1, 2024, at 8:01 PM, Ian Lance Taylor  
>>> wrote: 
>>> > > 
>>> > > On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein  
>>> wrote: 
>>> > >> 
>>> > >> I'm struggling to understand if I'm able to do something. 
>>> > >> 
>>> > >> 
>>> > >> In my very odd use case we are writing a websever that handles 
>>> connections via a forked process. 
>>> > >> 
>>> > >> I have a listener process that listens for TCP connections. 
>>> > >> 
>>> > >> So each net.Conn that comes in we pull off its file descriptor: 
>>> > >> 
>>> > >> fd, err := conn.(*net.TCPConn).File() 
>>> > >> 
>>> > >> duplicate that file descriptor and then fork off a process passing 
>>> in that file descriptor. 
>>> > >> 
>>> > >> In my forked handler I'll reconstruct the HTTP connection and "do 
>>> stuff". 
>>> > >> 
>>> > >> The concern I'm having is that it appears when I fork a process I 
>>> inherit all of the parent file descriptors so if I have say 5 incoming 
>>> connections and then I fork my child process technically could write to a 
>>> different connection. 
>>> > >> 
>>> > >> I've played around with the various options: 
>>> > >> 
>>> > >> cmd.SysProcAttr = {Setpgid: false,} 
>>> > >> 
>>> > >> and using cmd.ExtraFiles 
>>> > >> 
>>> > >> No matter what I do I seem unable to limit the sub process to ONLY 
>>> using the specific File Descriptor I want it to have access to. 
>>> > >> 
>>> > >> I believe this is doable in C - but I'm not sure if I can do this 
>>> in GoLang as-is without mods . 
>>> > > 
>>> > > What you are describing shouldn't happen. A child process should 
>>> only 
>>> > > get the file descriptors explicitly passed via the os/exec.Cmd 
>>> fields 
>>> > > Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and 
>>> > > version of Go, and what is showing you that all file descriptors are 
>>> > > being passed down to the child. 
>>> > > 
>>> > > 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...@googlegroups.com. 
>>> > > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%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/34b77595-6a2c-41f2-9ef7-9296c9c92176n%40googlegroups.com.

[go-nuts] text template range over Rangefunc

[Ajay Kidave]

The https://go.dev/wiki/RangefuncExperiment change will be a great addition 
to the language. I wanted to know whether the text/html template std 
libraries will allow range over rangefunc. Currently, the doc for 
text/template 

 
says

{{range pipeline}} T1 {{end}}
The value of the pipeline must be an array, slice, map, or channel

It would be great if rangefunc is supported in templates. The specific use 
case for me is passing a rangefunc created on a sql row iterator to a 
template.

-- 
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/7b920383-306e-4a73-b7be-c994470fc04bn%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Mike Schinkel]

> On Mar 4, 2024, at 12:18 PM, Jeremy French  wrote:
> 
> More, to prevent PrintMonth(14) which the function would have to check for 
> and either return an error or panic, since there is no meaningful output. ... 
>  I was more just answering Mike Schinkel's question about why it would be 
> useful.

Thank you for answering my question.

I tried to come up with a solution to that problem in Go using existing 
features and — assuming we want our enum-like values to be immutable and we 
don't want write a large amount of boilerplate — I was not successful.

> On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote:
> Does this represent the problem statement?
> https://go.dev/play/p/kLME_dJE9a5 

I'd like to present my simple analysis of the catch-22 and see if others concur?

1. In order to get immutability without significant boilerplate, we need to use 
`const`.

2. We *can* define a type like `Month` as Brian Candler's example showed.

3. We also can assign values of our type to our `const` constants.

4. However, we can *only* assign literals or simple expressions to a `const`. 
i.e. we cannot assign `Month{1}` to a `const` if `Month` were a `struct`, 
`map`, `array`, or `slice`.

5. Further, funcs allow literals to be used as a type without requiring them to 
be cast as that type which is why `PrintMonth(14)` is both possible and 
problematic.

6. All values that we can validly assigned to a `const` are literal values that 
can also stand-in for the type when passed to a func that expects that type as 
a parameter.

Does that summarize our quandary correctly?  Did I leave anything out?

Assuming I did summarized correctly then it seems that any one or more of these 
potentially simple language enhancements would suffice to address the stated 
concern?

1. Allow a `const` to somehow be defined as `strict` where `strict` is a 
placeholder for the concept; i.e. that  `PrintMonth(14)` would not be possible 
but  `PrintMonth(April)` would be.

2. Allow a `func` too somehow have its parameter defined as `strict`, i.e. that 
again, `PrintMonth(14)` would not be possible but  `PrintMonth(April)` would be.

3. Allow a `var` to somehow be defined as immutable thus allowing immutable 
vars and 
types of subtypes `struct`, `map`, array, and/or slices to be used as 
pseudo-enums.

4. Relax the allowable values that can be assigned to a `const` to include 
values that can be fully determined at compile time such as `const April = 
[1]byte{4}` thus allowing `const` and 
types of subtypes `struct`, `map`,  array, and/or slices to be used as 
pseudo-enums.

Did I miss any potentials?  Did I get anything wrong? 


-Mike

P.S. Seems to me that #4 might be the simplest way forward as it would allow 
for creation of types that cannot be represented as their literal subtype value 
to pass as a parameter to a `func`, and it would not require any new keywords 
or concepts added to Go the language, or at least I don't think it would? 

Is there any reason Go could not relax the allowable values for const to be 
able to support constructs that can be determined at runtime such as `const 
April = [1]byte{4}`?

As an aside, if this solution is viable then it would also be nice if the cast 
`Month(4)` could translate to `[1]byte{4}` when `Month` is defined as 
`[1]byte`, and equivalent for `struct` and slices, i.e. that `Month(4) would 
assign to the first element or property of the `struct`, array, or slice. It 
could easily be limited to those with only one element or property, though.

-- 
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/21C8009D-F312-45CE-99C7-2B017603F60B%40newclarity.net.

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

[Jeff Stein]

I think I may have discovered the issue.

I made a sys call to duplicate the file descriptor

dupFd, err := syscall.Dup(int(file.Fd()))
if err != nil {
log.Printf("Error duplicating file descriptor: %v", err)
return 0, ""
}

which likely reset the FD_CLOEXEC Flag:

(from Advanced Programming in the Unix Environment) - section 3.12:

*The new file descriptor returned by dup is guaranteed to be the 
lowest-numbered available file descriptor. With dup2, we specify the value 
of the new descriptor with the fd2 argument. If fd2 is already open, it is 
first closed. If fd equals fd2, then dup2 returns fd2 without closing it. 
Otherwise, the FD_CLOEXEC file descriptor flag is cleared for fd2, so 
that fd2 is left open if the process calls exec.*
Does this sound like what may have been happening?

On Monday, March 4, 2024 at 9:04:31 AM UTC-7 Jeff Stein wrote:

> OP here -> I'm going to put together some test apps - toss them on GitHub 
> and make sure I actually know what I'm talking about :) 
>
> On Friday, March 1, 2024 at 7:57:15 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Fri, Mar 1, 2024 at 6:17 PM Robert Engels  
>> wrote: 
>> > 
>> > The could be calling fork() as in the system call - which copies all 
>> file descriptors but I didn’t think Go processes could fork. 
>> > 
>> > Seems you would need to remap stdin and stdout in the fork to do 
>> anything useful. 
>> > 
>> > This sounds very PHP - what goes around comes around. 
>>
>> Good point, I am assuming that the OP is using the os/exec package to 
>> start up a new copy of the process. 
>>
>> A simple fork without an exec can't work in Go, or in any 
>> multi-threaded program. 
>>
>> Ian 
>>
>>
>> > > On Mar 1, 2024, at 8:01 PM, Ian Lance Taylor  
>> wrote: 
>> > > 
>> > > On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein  
>> wrote: 
>> > >> 
>> > >> I'm struggling to understand if I'm able to do something. 
>> > >> 
>> > >> 
>> > >> In my very odd use case we are writing a websever that handles 
>> connections via a forked process. 
>> > >> 
>> > >> I have a listener process that listens for TCP connections. 
>> > >> 
>> > >> So each net.Conn that comes in we pull off its file descriptor: 
>> > >> 
>> > >> fd, err := conn.(*net.TCPConn).File() 
>> > >> 
>> > >> duplicate that file descriptor and then fork off a process passing 
>> in that file descriptor. 
>> > >> 
>> > >> In my forked handler I'll reconstruct the HTTP connection and "do 
>> stuff". 
>> > >> 
>> > >> The concern I'm having is that it appears when I fork a process I 
>> inherit all of the parent file descriptors so if I have say 5 incoming 
>> connections and then I fork my child process technically could write to a 
>> different connection. 
>> > >> 
>> > >> I've played around with the various options: 
>> > >> 
>> > >> cmd.SysProcAttr = {Setpgid: false,} 
>> > >> 
>> > >> and using cmd.ExtraFiles 
>> > >> 
>> > >> No matter what I do I seem unable to limit the sub process to ONLY 
>> using the specific File Descriptor I want it to have access to. 
>> > >> 
>> > >> I believe this is doable in C - but I'm not sure if I can do this in 
>> GoLang as-is without mods . 
>> > > 
>> > > What you are describing shouldn't happen. A child process should only 
>> > > get the file descriptors explicitly passed via the os/exec.Cmd fields 
>> > > Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and 
>> > > version of Go, and what is showing you that all file descriptors are 
>> > > being passed down to the child. 
>> > > 
>> > > 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...@googlegroups.com. 
>> > > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%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/c4b9cff2-ae25-45c4-829e-b402fae38135n%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Nicolas Serna]

I think what Jeremy mentions in here is the key to the issue. There would 
be more consensus and less interest in "fixing" enums in Go if there was a 
tangible way to restrict their values to what is stated by the developer.

El lunes, 4 de marzo de 2024 a la(s) 12:18:05 p.m. UTC-3, Jeremy French 
escribió:

What I find valuable is to be able to accept an enum as a parameter to a 
function, and know that it will be one of several approved values (e.g. 
month of the year), without having to have boiler plate to check or throw 
errors if it's not one of the approved values.  It's checked at 
compile-time rather than run time.  Whether that could be handled via 
go:generate or not, I wouldn't know.  I haven't used go:generate, but 
frankly at first glance it seems like using a sledgehammer to crack a 
walnut.  Maybe if you use go:generate regularly anyway, that would make 
sense.  But it seems like overkill to involve go:generate just to be able 
to have enums.  But again, my familiarity with go:generate is that which 
you get from 30 seconds of a google search.


On Sunday, March 3, 2024 at 5:32:24 PM UTC-5 Mike Schinkel wrote:

I have recently seen many are complaining about a lack of enums in Go.  But 
while there are many ways in which I would like to see Go improved, enums 
barely even rank on my list of priorities.

The majority of my experience prior to Go was with dynamic languages that 
did not have explicit enums, and in working with Go I never really felt 
that enum functionality was missing.

That said, what am I missing?  What it is about enums that have so many 
people clamoring for them in Go?  Is it having a textual representation 
managed by the compiler that a go:generate cannot solve?  Is it having a 
syntax that allows treating them like an object with a property, e.g. 
HttpStatuses.NotFound that otherwise requires too much boilerplate?  Or is 
it something else?

Further, what can you envision doing with a "proper" enum that you cannot 
already do with a custom-typed constant?

Thank you in advance to whoever helps me understand why enums are such as 
burning desire for so many developers.

-Mike

On Mar 3, 2024, at 12:25 AM, Nicolas Serna  wrote:

Hello, gophers. Lately I've been working quite a bit with enums as I'm 
moving a C program I had tGo, so I wondered if there was any progress on 
enums proposals and realized that none of them get anywhere without 
breaking the Go1 compatibility.


I've decided to get a bit creative and share with you the proposals I've 
thought of. 

The fundamental thing when we talk about the incorporation of "robust 
enums" is, similarly to the case of generics, to propose a syntax extension 
to the language without breaking compatibility with the previous software.

We use enumerations simply to handle states and encapsulate them under a 
name. Therefore I wanted to propose the following syntax:

```proposal
const ()   = 
```

The idea of this syntax is that, roughly speaking, it reminds us of what we 
do when we declare a method, with the only difference that in this case we 
use constant values associated to some "enum type". Then, we should be able 
to call our constants as follows: ., the same 
would be true for an already instantiated type.

```example
type Statement struct{ /* ... */ } 

type StatementTyp int 

const (Statement) (
 Prepared StatementTyp = iota
 Success
 Fail
)

func main() {
stmt := Statement{}
fmt.Println(Statement.Prepared) // 0
fmt.Println(stmt.Success) // 1
}
```

Realistically speaking this doesn't solve much. It just gives us a way to 
encapsulate constants in an "elegant" way and keeps the "const-iota" 
syntax, but little else.

I think it is essential to have an extra way to reference these internal 
values of a type so that we can work with the help of the go-typechecker. 
For this I could only come up with two types of syntax, let's see:

```prop1
var bar const 

func foo(arg const ) {...}
```
```prop2
var foo .const

func bar(arg .const)
```

That would be all, I hope you can give some feedback and know what you 
think. I read in the go2-language-template 
 
that it was better to post my ideas in this group instead of making a issue.

Thanks for reading ^^


-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/134fd31b-9081-4d22-b098-412244338fc5n%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 

Re: [go-nuts] Query Regarding ASAN C Call from Go Code

[Ian Lance Taylor]

On Mon, Mar 4, 2024 at 9:55 AM Evgeny Chormonov  wrote:
>
> I'm using Linux as my platform, but I'm curious why this solution is 
> restricted to Linux systems only?
> https://github.com/golang/go/blob/master/src/runtime/asan/asan.go#L5

That's just the list of systems for which we support asan.  Offhand I
don't know what other systems the asan library supports.  I don't
think there is any obstacle to porting Go's asan support to other
systems that the asan library supports, though of course some such
ports would require new Go assembly code.

Ian


> понедельник, 4 марта 2024 г. в 00:43:09 UTC+3, Ian Lance Taylor:
>>
>> On Sun, Mar 3, 2024 at 1:25 PM Evgeny Chormonov  wrote:
>> >
>> > I noticed that ASAN checker in the Go source code is defined using CGO 
>> > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go
>> > But the C ASAN functions are called from the Go runtime using assembly 
>> > code instead of a common CGO call. 
>> > https://github.com/golang/go/blob/master/src/runtime/asan_amd64.s#L36
>> >
>> > This discovery has sparked my interest, and I am curious to know if I can 
>> > employ a similar method to execute my own C functions from my Go code. 
>> > Could you clarify if this is a viable option?
>>
>> Viable is in the eyes of the beholder. You can use a similar method.
>> But you have to hand-write the assembler code for each C function you
>> want to call. And if the C function ever blocks on, say, network I/O,
>> your entire Go program can hang unexpectedly. We only use this
>> technique for ASAN because we have a very limited number of functions
>> to call, and we know for sure that those functions can never block.
>>
>> 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/e5dd08b6-2e05-4bf2-9f51-89d2cb55622fn%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/CAOyqgcVEbVvz%2BTJYGtKbZe-3gETWWwC%2Bs1%3Dygahv9czC6xt_ug%40mail.gmail.com.

Re: [go-nuts] Enums, Go1 and proposals

[Ian Lance Taylor]

On Mon, Mar 4, 2024 at 9:40 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> The static type of an interface can be verified at compile time. The
> value of a variable of an enum type (or a Pascal-like subrange) type,
> cannot be verified at compile time in the general case. You would have
> to add features Go does not have (like variable immutability) and/or
> restrict some features for enum types that Go does have (like taking
> address and using unsafe). Neither looks to me very probable, at least
> in a short time.
>
> Those values can be however checked at runtime, similarly to
> array/slice index bounds checking. For subrange-like enums it's rather
> cheap and can be often eliminated. General, sparse-valued enums are
> commonly too expensive to check at runtime for the compiler. to insert
> them automatically.

In order to use runtime checks reliably, then for something like an
enum field in a struct where we have a pointer to the struct, we would
have to validate the enum value each time it is used.  And presumably
panic if the value is out of range.  This is doable but it's hard for
me to believe that this is really what people want when they say that
they want enums.  In particular it's not how enums work in C/C++.  It
is arguably how enums work in Java and Python but since they don't
have pointers the situation is somewhat different.  Rust enums are
significantly different in that each enum value can have its own
individual attached data, making them more like tagged union types.

I think the biggest reason that we haven't added enums to Go, beyond
the predeclared constant iota, is that there is no consensus as to
what people actually want.  I'm not saying that if there was consensus
that we would add enum types.  But I do think it's very unlikely that
we would add enum types in the absence of consensus.

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/CAOyqgcVxUFges7bUGuK-nexBu%2BzmtZ%3DHeDMFTtDYe2pauHajxg%40mail.gmail.com.

Re: [go-nuts] Query Regarding ASAN C Call from Go Code

[Evgeny Chormonov]

Thanks for your answer, Ian. I've decided to use a code generator based on 
cgo instead of writing assembly code for each function.

I'm using Linux as my platform, but I'm curious why this solution is 
restricted to Linux systems only?
https://github.com/golang/go/blob/master/src/runtime/asan/asan.go#L5

понедельник, 4 марта 2024 г. в 00:43:09 UTC+3, Ian Lance Taylor: 

> On Sun, Mar 3, 2024 at 1:25 PM Evgeny Chormonov  
> wrote:
> >
> > I noticed that ASAN checker in the Go source code is defined using CGO 
> https://github.com/golang/go/blob/master/src/runtime/asan/asan.go
> > But the C ASAN functions are called from the Go runtime using assembly 
> code instead of a common CGO call. 
> https://github.com/golang/go/blob/master/src/runtime/asan_amd64.s#L36
> >
> > This discovery has sparked my interest, and I am curious to know if I 
> can employ a similar method to execute my own C functions from my Go code. 
> Could you clarify if this is a viable option?
>
> Viable is in the eyes of the beholder. You can use a similar method.
> But you have to hand-write the assembler code for each C function you
> want to call. And if the C function ever blocks on, say, network I/O,
> your entire Go program can hang unexpectedly. We only use this
> technique for ASAN because we have a very limited number of functions
> to call, and we know for sure that those functions can never block.
>
> 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/e5dd08b6-2e05-4bf2-9f51-89d2cb55622fn%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jan Mercl]

On Mon, Mar 4, 2024 at 6:19 PM Jeremy French  wrote:

> More, to prevent PrintMonth(14), which the function would have to check for 
> and either return an error or panic, since there is no meaningful output.  In 
> fact, it's fairly easy to see, even in this case, where the PrintMonth 
> signature would have to return an error, when that is pretty much the only 
> case where it would need to.  With an enum as an input parameter, the 
> PrintMonth() function would not need to have the error return value.  It's 
> the same type of philosophy around interfaces.  If you accept as an input 
> parameter an interface that has a PrintMonth() function, then you don't have 
> to double check that the passed struct/object has a PrintMonth() function. 
> You can just use it.

The static type of an interface can be verified at compile time. The
value of a variable of an enum type (or a Pascal-like subrange) type,
cannot be verified at compile time in the general case. You would have
to add features Go does not have (like variable immutability) and/or
restrict some features for enum types that Go does have (like taking
address and using unsafe). Neither looks to me very probable, at least
in a short time.

Those values can be however checked at runtime, similarly to
array/slice index bounds checking. For subrange-like enums it's rather
cheap and can be often eliminated. General, sparse-valued enums are
commonly too expensive to check at runtime for the compiler. to insert
them automatically.

-- 
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-X3B8je11%3DmZ98UBwWLAVkmOB-LweJCd_QU5xVqd%3Duiqg%40mail.gmail.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jeremy French]

More, to prevent PrintMonth(14), which the function would have to check for 
and either return an error or panic, since there is no meaningful output.  
In fact, it's fairly easy to see, even in this case, where the PrintMonth 
signature would have to return an error, when that is pretty much the only 
case where it would need to.  With an enum as an input parameter, the 
PrintMonth() function would not need to have the error return value.  It's 
the same type of philosophy around interfaces.  If you accept as an input 
parameter an interface that has a PrintMonth() function, then you don't 
have to double check that the passed struct/object has a PrintMonth() 
function. You can just use it.  If you accept a Month enum as an input 
parameter, you don't have to check that it's between 1 and 12 inclusive.

BTW, this isn't something I'm passionate about.  I was more just answering 
Mike Schinkel's question about why it would be useful.

On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote:

> On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote:
>
> What I find valuable is to be able to accept an enum as a parameter to a 
> function, and know that it will be one of several approved values (e.g. 
> month of the year)
>
>
> ISTM all that's needed is to have a way to create a named type which 
> cannot be assigned from the values of the underlying type, except inside a 
> const declaration.
>
> Does this represent the problem statement?
> https://go.dev/play/p/kLME_dJE9a5
>
>

-- 
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/2af024e7-e7bf-4ed9-aaf4-58bade052aeen%40googlegroups.com.

Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec

[Jeff Stein]

OP here -> I'm going to put together some test apps - toss them on GitHub 
and make sure I actually know what I'm talking about :) 

On Friday, March 1, 2024 at 7:57:15 PM UTC-7 Ian Lance Taylor wrote:

> On Fri, Mar 1, 2024 at 6:17 PM Robert Engels  wrote:
> >
> > The could be calling fork() as in the system call - which copies all 
> file descriptors but I didn’t think Go processes could fork.
> >
> > Seems you would need to remap stdin and stdout in the fork to do 
> anything useful.
> >
> > This sounds very PHP - what goes around comes around.
>
> Good point, I am assuming that the OP is using the os/exec package to
> start up a new copy of the process.
>
> A simple fork without an exec can't work in Go, or in any
> multi-threaded program.
>
> Ian
>
>
> > > On Mar 1, 2024, at 8:01 PM, Ian Lance Taylor  wrote:
> > >
> > > On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein  wrote:
> > >>
> > >> I'm struggling to understand if I'm able to do something.
> > >>
> > >>
> > >> In my very odd use case we are writing a websever that handles 
> connections via a forked process.
> > >>
> > >> I have a listener process that listens for TCP connections.
> > >>
> > >> So each net.Conn that comes in we pull off its file descriptor:
> > >>
> > >> fd, err := conn.(*net.TCPConn).File()
> > >>
> > >> duplicate that file descriptor and then fork off a process passing in 
> that file descriptor.
> > >>
> > >> In my forked handler I'll reconstruct the HTTP connection and "do 
> stuff".
> > >>
> > >> The concern I'm having is that it appears when I fork a process I 
> inherit all of the parent file descriptors so if I have say 5 incoming 
> connections and then I fork my child process technically could write to a 
> different connection.
> > >>
> > >> I've played around with the various options:
> > >>
> > >> cmd.SysProcAttr = {Setpgid: false,}
> > >>
> > >> and using cmd.ExtraFiles
> > >>
> > >> No matter what I do I seem unable to limit the sub process to ONLY 
> using the specific File Descriptor I want it to have access to.
> > >>
> > >> I believe this is doable in C - but I'm not sure if I can do this in 
> GoLang as-is without mods .
> > >
> > > What you are describing shouldn't happen. A child process should only
> > > get the file descriptors explicitly passed via the os/exec.Cmd fields
> > > Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and
> > > version of Go, and what is showing you that all file descriptors are
> > > being passed down to the child.
> > >
> > > 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...@googlegroups.com.
> > > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%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/fd650788-d500-4d44-8664-70ce57b917f3n%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

['Brian Candler' via golang-nuts]

On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote:

What I find valuable is to be able to accept an enum as a parameter to a 
function, and know that it will be one of several approved values (e.g. 
month of the year)


ISTM all that's needed is to have a way to create a named type which cannot 
be assigned from the values of the underlying type, except inside a const 
declaration.

Does this represent the problem statement?
https://go.dev/play/p/kLME_dJE9a5

-- 
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/480133d3-9795-4e2d-878d-1750c9b6c806n%40googlegroups.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jan Mercl]

On Mon, Mar 4, 2024 at 4:19 PM Jeremy French  wrote:

> It's checked at compile-time rather than run time.

That requires immutability of variables of enum type. Go does not
support immutable variables.

-- 
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-VuzKbH%2BztAMGqS867a0KqpE-v7t58dWMCJBdt1PDZ0Zg%40mail.gmail.com.

Re: [go-nuts] Enums, Go1 and proposals

[Jeremy French]

What I find valuable is to be able to accept an enum as a parameter to a 
function, and know that it will be one of several approved values (e.g. 
month of the year), without having to have boiler plate to check or throw 
errors if it's not one of the approved values.  It's checked at 
compile-time rather than run time.  Whether that could be handled via 
go:generate or not, I wouldn't know.  I haven't used go:generate, but 
frankly at first glance it seems like using a sledgehammer to crack a 
walnut.  Maybe if you use go:generate regularly anyway, that would make 
sense.  But it seems like overkill to involve go:generate just to be able 
to have enums.  But again, my familiarity with go:generate is that which 
you get from 30 seconds of a google search.


On Sunday, March 3, 2024 at 5:32:24 PM UTC-5 Mike Schinkel wrote:

> I have recently seen many are complaining about a lack of enums in Go. 
>  But while there are many ways in which I would like to see Go improved, 
> enums barely even rank on my list of priorities.
>
> The majority of my experience prior to Go was with dynamic languages that 
> did not have explicit enums, and in working with Go I never really felt 
> that enum functionality was missing.
>
> That said, what am I missing?  What it is about enums that have so many 
> people clamoring for them in Go?  Is it having a textual representation 
> managed by the compiler that a go:generate cannot solve?  Is it having a 
> syntax that allows treating them like an object with a property, e.g. 
> HttpStatuses.NotFound that otherwise requires too much boilerplate?  Or is 
> it something else?
>
> Further, what can you envision doing with a "proper" enum that you cannot 
> already do with a custom-typed constant?
>
> Thank you in advance to whoever helps me understand why enums are such as 
> burning desire for so many developers.
>
> -Mike
>
> On Mar 3, 2024, at 12:25 AM, Nicolas Serna  wrote:
>
> Hello, gophers. Lately I've been working quite a bit with enums as I'm 
> moving a C program I had tGo, so I wondered if there was any progress on 
> enums proposals and realized that none of them get anywhere without 
> breaking the Go1 compatibility.
>
>
> I've decided to get a bit creative and share with you the proposals I've 
> thought of. 
>
> The fundamental thing when we talk about the incorporation of "robust 
> enums" is, similarly to the case of generics, to propose a syntax extension 
> to the language without breaking compatibility with the previous software.
>
> We use enumerations simply to handle states and encapsulate them under a 
> name. Therefore I wanted to propose the following syntax:
>
> ```proposal
> const ()   = 
> ```
>
> The idea of this syntax is that, roughly speaking, it reminds us of what 
> we do when we declare a method, with the only difference that in this case 
> we use constant values associated to some "enum type". Then, we should be 
> able to call our constants as follows: ., the 
> same would be true for an already instantiated type.
>
> ```example
> type Statement struct{ /* ... */ } 
>
> type StatementTyp int 
>
> const (Statement) (
>  Prepared StatementTyp = iota
>  Success
>  Fail
> )
>
> func main() {
> stmt := Statement{}
> fmt.Println(Statement.Prepared) // 0
> fmt.Println(stmt.Success) // 1
> }
> ```
>
> Realistically speaking this doesn't solve much. It just gives us a way to 
> encapsulate constants in an "elegant" way and keeps the "const-iota" 
> syntax, but little else.
>
> I think it is essential to have an extra way to reference these internal 
> values of a type so that we can work with the help of the go-typechecker. 
> For this I could only come up with two types of syntax, let's see:
>
> ```prop1
> var bar const 
>
> func foo(arg const ) {...}
> ```
> ```prop2
> var foo .const
>
> func bar(arg .const)
> ```
>
> That would be all, I hope you can give some feedback and know what you 
> think. I read in the go2-language-template 
>  
> that it was better to post my ideas in this group instead of making a issue.
>
> Thanks for reading ^^
>
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/134fd31b-9081-4d22-b098-412244338fc5n%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 

Re: [go-nuts] GO111MODULE=off go get deprecated?

['Bryan C. Mills' via golang-nuts]

Per https://go.dev/doc/go1.22#go-command:
> go get is no longer supported outside of a module in the legacy GOPATH mode 
(that is, with GO111MODULE=off). Other build commands, such as go build and go 
test, will continue to work indefinitely for legacy GOPATH programs.

This was discussed in https://go.dev/issue/60915, which simultaneously 
proposed to preserve `go build` and `go test` and to finish removing `go 
get` in GOPATH mode. (That proposal was a change to the plan stated 
in https://go.dev/blog/go116-module-changes, which said: “We plan to drop 
support for GOPATH mode in Go 1.17.” That clearly did not happen as planned 
in Go 1.17.)

The simplest way to download Go dependencies for code review and debugging 
is to run `go mod vendor` in your module or (newly added) `go work vendor` 
in your workspace. Also note that `go mod download -json` and `go list -m 
-json` now include origin information in most cases:

~$ go list -json -m go.uber.org/zap@v1.27.0
{
"Path": "go.uber.org/zap",
"Version": "v1.27.0",
"Time": "2024-02-20T20:55:06Z",
"GoMod": 
"/usr/local/google/home/bcmills/pkg/mod/cache/download/go.uber.org/zap/@v/v1.27.0.mod",
"GoVersion": "1.19",
"Origin": {
"VCS": "git",
"URL": "https://github.com/uber-go/zap;,
"Hash": "fcf8ee58669e358bbd6460bef5c2ee7a53c0803a",
"Ref": "refs/tags/v1.27.0"
}
}

On Sunday, March 3, 2024 at 10:12:45 PM UTC-5 Jeffery Carr wrote:

> I guess what I would add, is that it seems fair to say that the go-import 
> / go-source method of versioning is part of how GO works. It's part of the 
> GO API so to speak If I have to parse that output to clone the source repo 
> myself, then if GO changes, I have to change my code and it seems like it's 
> better if the standard is defined by GO in the first place. Either way, I 
> have to do it now (parse the HTML) and it would have been nice to have a 
> warning before I updated this morning to 1.22 and had it fail that the 
> GO111MODULE go get behavior was going to be deprecated in this release.
>
> jcarr
>
> On Sunday, March 3, 2024 at 8:57:04 PM UTC-6 Jeffery Carr wrote:
>
>> Yes, I do understand the go-source/go-import part, but  am I missing 
>> something? I don't understand how you would find the go-source other than 
>> parsing the HTML 
>>
>> I mean 'go get' used to do that for me, do I now have to write a program 
>> to do that? I don't understand why that is some bad idea. Yes, we can look 
>> at the curl output, but I need it to be programatic (I have lots of these 
>> repos so typing them in by hand is not really an option).
>>
>> Thanks,
>> jcarr
>>
>

-- 
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/33a07c97-20bf-4b2c-a99a-382d98309578n%40googlegroups.com.