Non pointer constraint for generic func

[Elad Gavra]

Hi,

I would like to create a non-pointer constraint for a generic function.

For example:

```

func F[T NonPtr](p T) {

// do something with p

}

```

Such that

```

F(MyStruct{}) // allowed

F(&MyStruct{}) // disallowed, compile time

```

I'm aiming to ensure, in compile-time, that a generic function, which is intended to work with values only, cannot be misused by passing in a pointer. (I can provide more context on my use case if needed.) While this could be enforced with a custom linter, I feel this should be a built-in capability of the language. From what I understand, though, this feature isn’t currently supported.

What do you think?

Thanks!

[Ian Lance Taylor]

In general Go generics allow the program to say that the type must
have a certain structure (see
https://go.dev/blog/deconstructing-type-parameters) but Go does not
permit the program to say that the type must _not_ have a certain
structure. In general this hasn't been a big problem. It is of
course possible to dynamically reject type structure at run time using
the reflect package, but there is no way to do it statically.

Personally I mostly think that is OK. One of the guidelines that Go
follows is to encourage people to write code rather than write types.
To me this falls into writing types.

That said, if we do decide to add facilities for rejecting type
structure, I don't think we should just add something to say "no
pointers, please." We should have a more general approach that also
allows us to say things like "no structs" or "no interface types."

Ian

[ben...@gmail.com]

Personally I mostly think that is OK. One of the guidelines that Go
follows is to encourage people to write code rather than write types.
To me this falls into writing types.

I'm intrigued by this concept, but I don't really know what it means. I've seen your (Ian's) similar comments at https://go.dev/blog/when-generics#write-code and https://github.com/golang/go/issues/29649#issuecomment-454820179 about the "general guideline for programming Go: write Go programs by writing code, not by defining types".

But can you flesh that out a bit, or -- even better -- point to some examples of what you do (and don't) mean? Or is there some "further reading" on the subject you can link to?

Does it simply mean to start by writing functions and imperative code, and worry about the types/structs as they come up?

-Ben

[Elad Gavra]

Thanks. I was about to reply with why I think we need it and then realized that my case does not justify it.

All I needed is a constraint that restricts to a set of known types which is available using the or op.

[Ian Lance Taylor]

Essentially, yes.

I think Rob Pike explains the idea well in
https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html.

Ian

[Ben Hoyt]

Ah yes, that does help, thanks. I've read that essay in the past, but it was a good re-read!