True, but that requires writing an additional definition and hides the parameter types, which can be very interesting, and you’d need a typedef for every new param combination I guess. It feels like a solution for a problem that could have been avoided by a better signature syntax in the first place.

I don’t think it’s that uncommon. Let’s say you have a function that handles a request. A common use case is to add permission checks before applying that function. You can write a generic permission check a bit like this:

func NeedsPermission(f func(Request) (Response, error), perm string) func(Request) (Response, error) {
    return func(r Request) (Response, error) {
        if !check(r, perm) {
            return nil, NewPermError(perm)
        }
        return f(r)
    }
}

// elsewhere
Bar := NeedsPermission(Foo, "superman")

This would allow you to separate the permission check logic from the business logic. Though to be fair, in Go they prefer to keep things as simple as possible but it’s just to illustrate that these concepts are not that alien.

This obviously just illustrates a point, but callbacks and decorators are not uncommon. And iterators are exactly like that:

type (
	Seq[V any]     func(yield func(V) bool)
	Seq2[K, V any] func(yield func(K, V) bool)
)

Which is very readable.

Go’s syntax is vastly superior once you have more complicated signatures, then the left-to-right truly matters. For example a variable that contains a pointer to a function that takes a function and an int and returns another function (like a decorator).

In C the order becomes very hard to understand and you really have to read the thing several times to understand the type of fp:

int (*(*fp)(int (*)(int, int), int))(int, int)

In Go, you can just read from left to right and you can easily understand what f’s type is:

f func(func(int,int) int, int) func(int, int) int

It’s just much more readable.

See: https://go.dev/blog/declaration-syntax

Debian sid is in the middle of a transition to 64 bit timestamps on 32 bit architectures. This requires a bump in all packages and an inconsistent repository is to be expected during this migration. Don’t use dist-upgrade and always carefully read what apt is about to do.

See: https://lists.debian.org/debian-devel-announce/2024/02/msg00005.html and https://lists.debian.org/debian-devel/2024/03/msg00092.html

Also, consider the following best practices when using sid: https://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2Fsid_users.3F