The definition in syscall_linux.go dates back to 5 years ago, but it does look mismatched.

/cc owners @ianlancetaylor @bradfitz @tklauser

I guess it depends whether changing it would do more good than harm.

I suspect it'd break a number of people and the benefit of changing it seems low-ish.

This looks like discrepancy. Refering to inotify man pages:
https://www.man7.org/linux/man-pages/man2/inotify_rm_watch.2.html

int inotify_rm_watch(int fd, int wd);

https://www.man7.org/linux/man-pages/man2/inotify_add_watch.2.html

int inotify_add_watch(int fd, const char *pathname, uint32_t mask);

wd and return values when adding watch in inotify are of the same types.

Go code is generated from: src/syscall/syscall_linux.go
Where we have:

...
//sys	InotifyAddWatch(fd int, pathname string, mask uint32) (watchdesc int, err error)
//sysnb	InotifyRmWatch(fd int, watchdesc uint32) (success int, err error)
...

uint32 is generally used for masks and modes

Even found in old articles it's always stated as int:
https://lwn.net/Articles/604686/

In linux kernel we can see:
any-linux-any/linux/inotify.h

/* For O_CLOEXEC and O_NONBLOCK */
#include <linux/fcntl.h>
#include <linux/types.h>

/*
 * struct inotify_event - structure read from the inotify device for each event
 *
 * When you are watching a directory, you will receive the filename for events
 * such as IN_CREATE, IN_DELETE, IN_OPEN, IN_CLOSE, ..., relative to the wd.
 */
struct inotify_event {
	__s32		wd;		/* watch descriptor */
	__u32		mask;		/* watch mask */
	__u32		cookie;		/* cookie to synchronize two events */
	__u32		len;		/* length (including nulls) of name */
	char		name[];	/* stub for possible name */
};

types.h
-> asm/types.h
-> asm-generic/types.h
-> asm-generic/int-ll64.h

showing

#ifndef __ASSEMBLY__
/*
 * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
 * header files exported to user space
 */

typedef __signed__ char __s8;
typedef unsigned char __u8;

typedef __signed__ short __s16;
typedef unsigned short __u16;

typedef __signed__ int __s32;
typedef unsigned int __u32;

Perhaps we made a mistake, but changing this now would just break existing working code for no benefit.

Ok, it would break existing working code, but this hangs for more than 5 years.
I've found a trace in api/go1.txt with same signature...

I would like to ask: when it could be fixed?

@ianlancetaylor Now we have versions, so maybe, there's a chance to have syscall/v2 package, with fixed discrepancies like this, without breaking backward compatibility ?

Yes, we could fix this with a v2 package. But it seems like a minor detail. Perhaps I've missed something, but is there anything that can't be done with the current implementation? Aren't we just talking about adding a type conversion that shouldn't be needed? And it's not like this is a widely used function.

It brings inconsistency and unnecessary checks/conversions on developer side.
That's why I wanted to address this.

Could you elaborate more on not widely used function?
Maybe now it's not so bad to bring this change?

It's not a widely used function, which means that few programmers will run into this inconsistency.

We take backward compatibility seriously (see https://go.dev/doc/go1compat), so even though only a few programs use this function we aren't going to break them without a really good reason.

The situation is clearly unfortunate, and I wish we had done better back when this function was introduced in 2010 (https://golang.org/cl/2241045). However, in a case like this, where there is no good solution and no clear path forward, not changing anything is the best of a set of bad choices.

Could we at least mark it to be fixed in future?

As long as we understand that the future is a very long way off, sure.