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
> 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
>>
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
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
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
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
>
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
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
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
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.
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"
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
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?
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
> 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
>
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`,
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
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
>
>
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
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
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
21 matches
Mail list logo
