Ah yes, that does help, thanks. I've read that essay in the past, but it
was a good re-read!
On Thu, 14 Nov 2024 at 11:24, Ian Lance Taylor wrote:
> On Wed, Nov 13, 2024 at 1:28 PM ben...@gmail.com
> wrote:
> >
> > > Personally I mostly think that is OK. One of the guidelines that Go
> > > foll
On Wed, Nov 13, 2024 at 1:28 PM ben...@gmail.com wrote:
>
> > 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 real
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.
On Wed, Nov 13, 2024, 19:23 Ian Lance Taylor wrote:
> On Wed, Nov 13, 2024 at 8:59
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
htt
On Wed, Nov 13, 2024 at 8:59 AM Elad Gavra wrote:
>
> 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
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, whi
