In golang.org/x/sys/windows, the WAIT_* return codes from
WaitForSingleObject and WaitForMultipleObjects are defined as untyped
integer constants except for WAIT_TIMEOUT, which is a syscall.Errno.

All the other syscall.Errno values less than 1700 (the first RPC_ error)
begin with ERROR_.

The WaitFor* functions above return WAIT_TIMEOUT as a uint32, not as an
error.  WAIT_TIMEOUT being an Errno makes using these functions slightly
more complicated.

I think the syscall.Errno should have been named ERROR_WAIT_TIMEOUT and
WAIT_TIMEOUT should have been an untyped constant.

The worst part about this situation is not that a type conversion is
required on the WAIT_TIMEOUT constant to make it useful, but the
cognitive load required to arrive at that solution.  Whether you realize
when first writing the code that WAIT_TIMEOUT is differently typed than
WAIT_OBJECT_0 and WAIT_ABANDONED or you find out the first time you
compile, you must then realize that windows.Errno is a type alias for
syscall.Errno, which is a uintptr, and the value for WAIT_TIMEOUT is
small enough to be safely converted to uint32 to match the return type
of the WaitFor* functions.

Even if you are already familiar with Errno, this is a moderate and
completely unnecessary cognitive load.  If you are not familiar, you
must read documentation or source code for both x/sys/windows and
syscall to resolve the issue.

To make things worse, syscall got it right!  syscall.WAIT_TIMEOUT is an
untyped integer constant.

Are there any other Windows API functions other than WaitFor*Object*
that use or return WAIT_TIMEOUT?  As far as I can tell, WAIT_TIMEOUT is
only used in a context where WAIT_OBJECT_0 and WAIT_ABANDONED are also
used.

Normally, I would hesitate to encourage changing this, but golang.org/x
is explicitly excluded from the compatibility guarantee to allow
incompatible changes that improve its usefulness, which I think this
change would do.  Anyone currently using WAIT_TIMEOUT would have the
choice of using gofmt (or their favorite editor) to rename it to
ERROR_WAIT_TIMEOUT or vendoring golang.org/x/sys.

I suspect many current uses of WAIT_TIMEOUT are in a switch statement as
uint32(windows.WAIT_TIMEOUT), which would compile just fine with the
change.

Thoughts?

...Marvin

-- 
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/20190926152241.pmhewuprsol465rk%40basil.wdw.

Reply via email to