Re: [go-nuts] generics question

Sorry for the noise - looks like you meant when passing around objects by this type, not just creating objects. On Friday, May 3, 2024 at 11:02:37 AM UTC-6 Kevin Chowski wrote: > If you are just unhappy about the A and A* while using a literal for C: > note that if you are willing/able to write

Re: [go-nuts] generics question

If you are just unhappy about the A and A* while using a literal for C: note that if you are willing/able to write a wrapper function instead of using a literal, type inference works well today: func NewC[E any, P Settable[E]](val []E) C[E, P] { return C[E, P]{Val: val} } var c = NewC([]A{1, 2,

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss wrote: > > This works, see my code below. Followup question: is there a way to refer to > the new type without having to list both the element type and the pointer > type separately? Unfortunately there is not. At some point in the future the langu

Re: [go-nuts] generics question

Thank you both! This works, see my code below. Followup question: is there a way to refer to the new type without having to list both the element type and the pointer type separately? Below I have to write C[A, *A], which looks slightly ugly. And in my real application something like Creator

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 9:54 PM Ian Lance Taylor wrote: > > On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote: > > > > Using generics, can I somehow write a constraint which says that *T > > (instead of T) implements a certain interface? The following code > > illustrated what I'm trying to do

Re: [go-nuts] generics question

On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote: > > Using generics, can I somehow write a constraint which says that *T (instead > of T) implements a certain interface? The following code illustrated what > I'm trying to do: > > type A int > > func (a *A) Set(x int) { > *a = A(x) > } > > typ

[go-nuts] generics question

Using generics, can I somehow write a constraint which says that *T (instead of T) implements a certain interface? The following code illustrated what I'm trying to do: type A int func (a *A) Set(x int) { *a = A(x) } type B string func (b *B) Set(x int) { *b = B(strconv.Itoa(x)) } type C1 s

Re: [go-nuts] [generics] type constraint for structs

It allows to return the value pointed at (*Element) but I still don't have access to the *Element field adddress of let's say var d Div so can't change d.Element to swap it with another value. (by taking Ref(&d,e) where e is some *Element) It's usable as a constraint but that's not sufficient.

Re: [go-nuts] [generics] type constraint for structs

How does `interface{ AsElement() *Element }` not do exactly what you want? On Thu, Apr 4, 2024 at 4:14 AM atd...@gmail.com wrote: > Might have come across this today as I was trying to simplify some code. > > Basically, I have a base type called *Element that has a method > AsElement() *Element

Re: [go-nuts] [generics] type constraint for structs

Ah, I forgot to use reflection for instance... That might be doable. On Thursday, April 4, 2024 at 4:13:35 AM UTC+2 atd...@gmail.com wrote: > Might have come across this today as I was trying to simplify some code. > > Basically, I have a base type called *Element that has a method > AsElement()

Re: [go-nuts] [generics] type constraint for structs

Might have come across this today as I was trying to simplify some code. Basically, I have a base type called *Element that has a method AsElement() *Element that returns itself. And this base element is used as a base for many others, for isntance: type Div struct{ *Element} type Span struct{*

Re: [go-nuts] [generics] type constraint for structs

While this would make some things much easier for me, it seems this would be a pretty fundamental change. Constraints are essentially interfaces and interfaces in Go are defined by behaviors. Structs, on the other hand, are defined by properties. There is no behavior that all structs have that

Re: [go-nuts] [generics] type constraint for structs

Same here @Abraham, ResponseType interface { ~struct{} } Obviously this doesn't work, I would love to see it working though. On Wednesday 14 September 2022 at 17:48:19 UTC+3 Abraham wrote: > I am glad I found this thread because I was just now breaking my head > figuring out wh

[go-nuts] Generics and "static" adapters

Ever since 1.18 came out I've been struggling to find an idiomatic way to implement a certain kind of adapter. I'm starting to suspect I'm Holding It Wrong (TM) so here I am. In short, I have an adapter that is effectively a collection of static methods and it doesn't look right. Imagine you h

Re: [go-nuts] [generics] instantiation of structs within generic functions

On Thursday, 8 June 2023 at 22:23:51 UTC-6 Ian Lance Taylor wrote: On Thu, Jun 8, 2023 at 8:59 PM Jim Minter wrote: > > I'm rather confused by instantiation of structs in generic functions. I happen to be using go protobufs. Unlike with `json.Unmarshal`, `proto.Unmarshal` expects to receive a

Re: [go-nuts] [generics] instantiation of structs within generic functions

On Thu, Jun 8, 2023 at 8:59 PM Jim Minter wrote: > > I'm rather confused by instantiation of structs in generic functions. I > happen to be using go protobufs. Unlike with `json.Unmarshal`, > `proto.Unmarshal` expects to receive a fully pre-instantiated struct to > unmarshal into. The non-ge

[go-nuts] [generics] instantiation of structs within generic functions

Hi, I'm rather confused by instantiation of structs in generic functions. I happen to be using go protobufs. Unlike with `json.Unmarshal`, `proto.Unmarshal` expects to receive a fully pre-instantiated struct to unmarshal into. The non-generic case looks like this: var _ proto.Message = (*Fo

Re: [go-nuts] generics: can I require "comparable" together with some methods?

Thanks again, reading the blog post indeed solved the problem! On Friday, 17 February 2023 at 23:47:09 UTC Ian Lance Taylor wrote: > On Fri, Feb 17, 2023 at 3:34 PM Jochen Voss wrote: > > > > I'm trying to write a generic function like the following (simplified) > one: > > > > type V interface

Re: [go-nuts] generics: can I require "comparable" together with some methods?

Dear Ian, Yes, I'm using 1.20.1. I hadn't seen the blog post yet, will read this next. Thanks for pointing me at this. Judging from the first paragraph of the blog post alone, the change described there may not solve my problem, though. All the best, Jochen On Friday, 17 February 2023 at 23

Re: [go-nuts] generics: can I require "comparable" together with some methods?

On Fri, Feb 17, 2023 at 3:34 PM Jochen Voss wrote: > > I'm trying to write a generic function like the following (simplified) one: > > type V interface { > comparable // (1) > SomeMethod(V) > } > > func Test[val V](x val) { > m := make(map[val]int) // (2) > // uses a x as key in a

[go-nuts] generics: can I require "comparable" together with some methods?

Hello, I'm trying to write a generic function like the following (simplified) one: type V interface { comparable // (1) SomeMethod(V) } func Test[val V](x val) { m := make(map[val]int) // (2) // uses a x as key in a map and calls x.SomeMethod() } When I try this, see https://go.

Re: [go-nuts] Generics in gollvm

On Tue, Dec 13, 2022 at 9:09 AM Andrey Bokhanko wrote: > > Do you have any idea on when generics support in gofrontend might be finished? Sorry, I don't. I understand the interest but I simply don't know. Ian -- You received this message because you are subscribed to the Google Groups "golan

Re: [go-nuts] Generics in gollvm

Hi Ian, Thanks for the update! Do you have any idea on when generics support in gofrontend might be finished? (To clarify, I don't want to "push" you at all; understandably, you have a lot on your plate and have to juggle different priorities. My only point is to have at least some understand

Re: [go-nuts] Generics in gollvm

On Sun, Dec 11, 2022, 7:11 AM Alex Markin wrote: > Hello. > > What is the status of generic programming (I mean the generics > > added in go-1.18) in the gollvm project? Are there any plans to support it > or maybe so

[go-nuts] Generics in gollvm

Hello. What is the status of generic programming (I mean the generics added in go-1.18) in the gollvm project? Are there any plans to support it or maybe someone already working on it? -- You received this message be

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Note for posterity: Other methods of method equality fall in the same problem, such as detailed in: https://stackoverflow.com/questions/9643205/how-do-i-compare-two-functions-for-pointer-equality-in-the-latest-go-weekly Proof: https://go.dev/play/p/aeeRKfderY2 On Monday, November 7, 2022 at 10:

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Thanks Ian for being generous with your time in answering this. I'll see if I can drum up another way to make that check work. Cheers and have a good rest of your day. On Monday, November 7, 2022 at 10:02:28 AM UTC-8 Ian Lance Taylor wrote: > On Mon, Nov 7, 2022 at 9:24 AM John wrote: > > > >

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

On Mon, Nov 7, 2022 at 9:24 AM John wrote: > > Or maybe I'm just doing something wrong. > > I have a struct implementing generics where methods return the next method to > execute. > > For tests, I wanted to make sure the returned method was the one expected, so > I was using this: > > nextStag

[go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

Or maybe I'm just doing something wrong. I have a struct implementing generics where methods return the next method to execute. For tests, I wanted to make sure the returned method was the one expected, so I was using this: nextStageName := runtime.FuncForPC(reflect.ValueOf(nextStage).Pointe

Re: [go-nuts] Generics: Is this not supported ?

On Tue, Oct 25, 2022 at 7:38 AM Elemer Pixard wrote: > > I am trying to create a generic function which returns > a Container with a slice of the specified type T: > https://go.dev/play/p/GS_x9Y8HOMK > Is this not supported or am I doing something wrong ? I'm not quite sure why that doesn't work.

[go-nuts] Generics: Is this not supported ?

I am trying to create a generic function which returns a Container with a slice of the specified type T: https://go.dev/play/p/GS_x9Y8HOMK Is this not supported or am I doing something wrong ? Regards. -- You received this message because you are subscribed to the Google Groups "golang-nuts" gr

Re: [go-nuts] [generics] type constraint for structs

I am glad I found this thread because I was just now breaking my head figuring out why my was not working On Wednesday, May 18, 2022 at 10:41:29 PM UTC-4 Ian Lance Taylor wrote: > On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis wrote: > > > > Where exactly did this land? Seems like an import

Re: [go-nuts] Generics type interference on "T | []T" to get T?

If you don't mind me extending the topic a bit: I bumped into a similar issue, which I described here: https://stackoverflow.com/questions/73591149/generics-type-inference-when-cascaded-calls-of-generic-functions One of the solutions for the original question would be to use something like: ty

Re: [go-nuts] Generics type interference on "T | []T" to get T?

Indeed. In hindsight, I should've predicted that. I think you are SOOL then, in general. I'd suggest using ~[]E directly and do the "scalar" case as a 1-element slice then. For a function, you can write `func F[E any](e ...E)`, which makes it callable with any number of arguments. Or `func F[E any

Re: [go-nuts] Generics type interference on "T | []T" to get T?

Gave it a try on playground, but this unfortunately raises the error "term cannot be a type parameter" for the E | ~[]E. On Friday, August 12, 2022 at 3:18:05 PM UTC+2 axel.wa...@googlemail.com wrote: > type ScalarOrSlice[E any] interface { > E | ~[]E > } > > func New[E any, T ScalarOrSlice

Re: [go-nuts] Generics type interference on "T | []T" to get T?

type ScalarOrSlice[E any] interface { E | ~[]E } func New[E any, T ScalarOrSlice[E]](v T) { … } Though I haven't tested this. On Fri, Aug 12, 2022 at 3:07 PM TheDiveO wrote: > I would like to provide a generics-based type-safe API that accepts either > a scalar or slice of some type T (not

[go-nuts] Generics type interference on "T | []T" to get T?

I would like to provide a generics-based type-safe API that accepts either a scalar or slice of some type T (not a type parameter), that is, the type constraint is (if I'm not mistaken) "T | []T". While I understand that this constraint would be declared as an interface (simplified example)...

[go-nuts] Generics types not inferred correctly on type switch cases

Let's consider the following situation: I have generic function which can accepts function arguments defined as any. Now if want to know exactly the type of function arguments I have to use the reflect package. The problem is that although on function invocation we can explicitly define the typ

[go-nuts] generics compile error: struct does not match interface, cannot infer type

anyone know why this simple case doesn't compile? i'm trying to call a function defined for generic interface type, which fails to compile for struct instance: https://go.dev/play/p/Y3Gdr2ILpK4 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Generics

Thanks Sebastien Le vendredi 27 mai 2022 à 19:21:43 UTC+2, Sebastien Binet a écrit : > what you may be looking at is (in the words of Rog Peppe) "structural > type constraints": > > https://go.dev/play/p/HiFc9CUfI7P > > -s > > On Fri May 27, 2022 at 18:32 CET, Martin Schnabel wrote: > > the reaso

Re: [go-nuts] Generics

what you may be looking at is (in the words of Rog Peppe) "structural type constraints": https://go.dev/play/p/HiFc9CUfI7P -s On Fri May 27, 2022 at 18:32 CET, Martin Schnabel wrote: > the reason your snippet does not work is that you pass in *payload as T > and the zero value of a pointer type

Re: [go-nuts] Generics

the reason your snippet does not work is that you pass in *payload as T and the zero value of a pointer type is nil and json unmarshal cannot with nil pointer values. so would need to pass in payload as T and *payload as P and somehow explain that P is *T and a encoding.BinaryUnmarshaler. I am

Re: [go-nuts] Generics

how about https://go.dev/play/p/YXOTLKpvXNI using json unmarshal directly and without using binary marshaller. or even https://go.dev/play/p/GFE3rnyx9f8 without the endpoint abstraction. or maybe explain what you want to achieve other than unmarshalling a json payload? best regards On 5/27/

[go-nuts] Generics

Hello, I do some tests with generics with Go 1.18. But I can't reach my goal. With https://go.dev/play/p/7kxMEWtXcPG I have: ``` panic: json: Unmarshal(nil *main.payload) goroutine 1 [running]: main.main() /tmp/sandbox3884661607/prog.go:43 +0x112 Program exited. ``` Because payload (li

Re: [go-nuts] [generics] type constraint for structs

On Wed, May 18, 2022 at 7:36 PM Jeremy Kassis wrote: > > Where exactly did this land? Seems like an important conversation... To date there is no way to write a constraint that requires that a type argument be a struct type. > ``` > // RPCHandler passes RPCReq and RPCRes as fn args > func RPCHa

Re: [go-nuts] [generics] type constraint for structs

Where exactly did this land? Seems like an important conversation... ``` // RPCHandler passes RPCReq and RPCRes as fn args func RPCHandler[T RPCReq, S RPCRes](fn func(T, S)) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { req := T{} if err := reqBodyRea

[go-nuts] [generics] generic method parameters

I've done many reading on Go generic method parameters, and it seems *somewhat* supported, like from https://markphelps.me/posts/trying-out-generics-in-go/ A generic Get() & Set() can be defined and used: // Set sets the value. func (o *Optional[T]) Set(v T) { o.

Re: [go-nuts] Generics faster than native float64?

FWIW, no difference on my MacBook. (base) michaels-mbp copybench % go test -bench=. goos: darwin goarch: amd64 pkg: localgo/copybench cpu: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz BenchmarkCopy-8 6999800 169.4 ns/op BenchmarkCopyG-86967590 170.6 ns/op PASS ok

Re: [go-nuts] Generics faster than native float64?

As Ian has pointed out, software and hardware optimizations may distort the results of microbenchmarks. If I run the original benchmarks using go1.18 and go1.19 the Copy and CopyG ns/op results are reversed. # Original: https://go.dev/play/p/m1ClnbdbdWi ~/x$ go1.18 version && go1.18 test x_0_t

Re: [go-nuts] Generics faster than native float64?

Thank you, yes, I took a look at the assembly and both generate MMX code, I did not check the preamble though. That said, the result is very consistent on my machine. Surprise. I am happy with no-overhead, so everything is good. On Mon, Apr 18, 2022 at 9:37 PM Ian Lance Taylor wrote: > On M

Re: [go-nuts] Generics faster than native float64?

On Mon, Apr 18, 2022 at 1:14 PM Feng Tian wrote: > > Hi, I have the following simple benchmark code, > > https://go.dev/play/p/m1ClnbdbdWi > > I run this on my laptop since Go playground does not run benchmark code. > The strange thing is that Copy of float64 is slower than copy using generics.

[go-nuts] Generics faster than native float64?

Hi, I have the following simple benchmark code, https://go.dev/play/p/m1ClnbdbdWi I run this on my laptop since Go playground does not run benchmark code. The strange thing is that Copy of float64 is slower than copy using generics. I can imagine generics may add no overhead, but how can i

Re: [go-nuts] generics: parametric types unmarshaling

On Fri Apr 15, 2022 at 10:52 CET, roger peppe wrote: > > what am I missing? > > how do I convey the constraint "unmarshaling usually imply passing a > > pointer to some value" ? > > > > This is a classic use case for structural type constraints: > https://go.dev/play/p/-stEjeeqQD0 thanks a lot! a

Re: [go-nuts] generics: parametric types unmarshaling

On Thu, 14 Apr 2022, 09:50 'Sebastien Binet' via golang-nuts, < golang-nuts@googlegroups.com> wrote: > hi there, > > I am playing a bit with generics. > I am trying to implement a parametrized "Read" function that unmarshals > bytes into some type value that implements an interface: > > type T1 st

[go-nuts] generics: parametric types unmarshaling

hi there, I am playing a bit with generics. I am trying to implement a parametrized "Read" function that unmarshals bytes into some type value that implements an interface: type T1 struct { v string } func (t *T1) UnmarshalBinary(p []byte) error { t.v = string(p) return n

Re: [go-nuts] Generics: Self Referencing Constraint Types

> > If you are willing to require a pointer receiver, you can do constraint > type inference: > https://go.dev/play/p/L2NiAAM8qE4 > A single cast worked nicely , thank you. -- You received this message because you are subscribed to the Google Groups "golang

Re: [go-nuts] Generics: Self Referencing Constraint Types

At its core, this is this restriction of the current generics design: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-way-to-require-pointer-methods That is, there is no real "nice" way to do it. If you are willing to require a pointer receiver, you can

[go-nuts] Generics: Self Referencing Constraint Types

Hi, please take a look . The aim is to write a HaveLess constraint that will work with any type like Large, without any reflection / traditional interfaces / dictionaries etc., just plain method calls. How would you write this? Keep in mind that type Large is

Re: [go-nuts] Generics question

This is brought up in the release notes: https://tip.golang.org/doc/go1.18#generics The Go compiler only supports calling a method m on a value x of type > parameter type P if m is explicitly declared by P's constraint interface. > Similarly, method values x.m and method expressions P.m also are o

[go-nuts] Generics question

I have the following code snippet. type workloadInterface interface { *appsV1.Deployment | *appsV1.StatefulSet } . . . func (a *adapter) processDepOrSSForSvc(client kubernetes.Interface, ns, svcName, workloadName, svcVersionType string) { switch svcVersionType { c

Re: [go-nuts] Generics: Whats the best way around limitation that methods can't be parameterized

On Thu, 2022-01-20 at 19:05 -0800, Mandolyte wrote: > Or perhaps a hybrid, where the methods call generic functions... > > On Thursday, January 20, 2022 at 7:23:37 PM UTC-5 Ian Lance Taylor > wrote: > > On Thu, Jan 20, 2022 at 3:30 AM Travis Keep > > wrote: > > > > > > I am working on a Pipeline[T

Re: [go-nuts] Generics: Whats the best way around limitation that methods can't be parameterized

Or perhaps a hybrid, where the methods call generic functions... On Thursday, January 20, 2022 at 7:23:37 PM UTC-5 Ian Lance Taylor wrote: > On Thu, Jan 20, 2022 at 3:30 AM Travis Keep wrote: > > > > I am working on a Pipeline[T, U any] type which receives any number of T > values and in turn e

Re: [go-nuts] Generics: Whats the best way around limitation that methods can't be parameterized

On Thu, Jan 20, 2022 at 3:30 AM Travis Keep wrote: > > I am working on a Pipeline[T, U any] type which receives any number of T > values and in turn emits U values. Pipelines are used to read from databases. > > For instance, this code fetches the ages of 5 people under 50. > > int[] ages > Peop

[go-nuts] Generics: Whats the best way around limitation that methods can't be parameterized

I am working on a Pipeline[T, U any] type which receives any number of T values and in turn emits U values. Pipelines are used to read from databases. For instance, this code fetches the ages of 5 people under 50. int[] ages PeopleOrderedByName(Start[Person](). Map(func(p Person) int { ret

[go-nuts] generics: Zero value for any type parameter

Hello, I've been playing with the new generics support in 1.18beta 1 today. I've come across a situation a couple of times where it would be convenient to be able to conjure the zero value for a variable corresponding to a type parameter. I've searched a bit for this to no avail. Understandab

[go-nuts] generics: what can we do with an any type?

Hello folks, I've stumbled over a thing and I don't understand if what I've found is intentionally possible by design... https://go.dev/play/p/SIxOV1FnTzX?v=gotip Why can I compare int with == when it was instantiated from the "any" type parameter? The origin of my question is my implementation

[go-nuts] generics: how to repeat type in parameters

How can I repeat the same generics type in the parameters? I'm getting a "does not match inferred type" error for the code below. func Print[T Worker](a T, b T) { fmt.Println(a.Work() + b.Work()) } func main() { c1 := coder{} t1 := tester{} Print(c1, t1) } Compiler Erro

Re: [go-nuts] [generics] Embedding interfaces

Awesome. Thanks muchly On Sat, May 8, 2021 at 11:40 PM Ian Lance Taylor wrote: > > On Fri, May 7, 2021 at 11:08 AM Viet Nguyen wrote: > > > > I'm trying to convert this code to use generics: > > > > type Cache interface { > > GetIfPresent(interface{}) (interface{}, bool) > > } > > > > type Loadi

Re: [go-nuts] [generics] Embedding interfaces

On Fri, May 7, 2021 at 11:08 AM Viet Nguyen wrote: > > I'm trying to convert this code to use generics: > > type Cache interface { > GetIfPresent(interface{}) (interface{}, bool) > } > > type LoadingCache interface { > Cache > Get(interface{}) (interface{}, error) > } > > However, I couldn't find

[go-nuts] [generics] Embedding interfaces

Hi, I'm trying to convert this code to use generics: type Cache interface { GetIfPresent(interface{}) (interface{}, bool) } type LoadingCache interface { Cache Get(interface{}) (interface{}, error) } However, I couldn't find any way to include Cache[K, V] in LoadingCache[K, V]. (No similar use

Re: [go-nuts] [generics] type switches

On Sun, Feb 21, 2021 at 4:44 AM thepud...@gmail.com wrote: > In any event, I am curious about the latest thinking and/or latest status. > If this has been discussed at length elsewhere since that August thread, I > would be happy for a pointer if anyone has one. > I think for the most part, you

[go-nuts] [generics] type switches

Hello fellow gophers, Ian announced the intention to update how type switches work in the generics proposal in a golang-nuts thread from this August: https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw It included this from Ian (which is a snippet of his item #4 from his first post ther

[go-nuts] [generics] feedback about generics

Hello everyone, First and foremost, thanks a lot for putting this together, it's been amazing. I just wanted to let you guys know that generics is looking very promising for me. Without generics, my codebase has things like: map_user, map_country, map_state etc, they basically take a collection o

Re: [go-nuts] [generics] notes on adding generics to a package

Am 07.02.2021 um 22:36 schrieb 'Axel Wagner' via golang-nuts: Some immediate thoughts on that: 1. It seems like a strange design decision, to let the importer mess with *any* exported interface type. it is, but it is simple. In general, Go takes a pretty firm stance that the semantics of a p

Re: [go-nuts] [generics] notes on adding generics to a package

Some immediate thoughts on that: 1. It seems like a strange design decision, to let the importer mess with *any* exported interface type. In general, Go takes a pretty firm stance that the semantics of a package should be determined by its author - for example, you can't add new methods to types.

Re: [go-nuts] [generics] notes on adding generics to a package

I follow the discussion about go generics for some time now, but never tried using them. Your conclusion > I struggled to grasp generics at the outset of this experiment. They are complex in a way that I haven’t encountered in a while with Go: I wasn’t sure when to reach for them and when to us

Re: [go-nuts] generics of go?

On Sun, Feb 7, 2021 at 2:49 AM xie cui wrote: > > i try to run the generic code, i find two branch dev.go2go, dev.typeparams, > the branch dev.go2go will translate generic to to no generic code and run it, > as far as i know. but i find the commit in dev.typeparams is more friendly > for me to

[go-nuts] generics of go?

i try to run the generic code, i find two branch dev.go2go, dev.typeparams, the branch dev.go2go will translate generic to to no generic code and run it, as far as i know. but i find the commit in dev.typeparams is more friendly for me to read, so how can i run the generic code by using dev.ty

Re: [go-nuts] [generics] notes on adding generics to a package

On Fri, Jan 29, 2021 at 1:09 PM Ben Burkert wrote: > > I wrote a blog post on my experience updating a package to use the > latest proposed generics feature with the go2go tool. My overall > impression is quite good as it was able to solve some existing > problems with the package. Thanks to Go te

[go-nuts] [generics] notes on adding generics to a package

Hi Gophers, I wrote a blog post on my experience updating a package to use the latest proposed generics feature with the go2go tool. My overall impression is quite good as it was able to solve some existing problems with the package. Thanks to Go team & gopher community for all your work making ge

Re: [go-nuts] Generics syntax suggestion

On Tue, Jan 19, 2021 at 11:45 PM Kevin Chadwick wrote: > On January 19, 2021 9:13:55 PM UTC, Levieux Michel > wrote: > >I think the question was: "given your proposal here, I can write func > >(string | []byte in1, string | []byte in2) which enforces that in1 and > >in2 > >must be either of type

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 22:44 +, Kevin Chadwick wrote: > On January 19, 2021 9:13:55 PM UTC, Levieux Michel < > mlevieu...@gmail.com> wrote: > > I think the question was: "given your proposal here, I can write > > func > > (string | []byte in1, string | []byte in2) which enforces that in1 > > and

Re: [go-nuts] Generics syntax suggestion

>>string >>or []byte) ? " >> > >You could always use a well placed &. That isn't the point. 😉 Or perhaps group with {} like Darts optional parameters. Again though, not the point. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscrib

Re: [go-nuts] Generics syntax suggestion

On January 19, 2021 9:13:55 PM UTC, Levieux Michel wrote: >I think the question was: "given your proposal here, I can write func >(string | []byte in1, string | []byte in2) which enforces that in1 and >in2 >must be either of type string or type []byte, but how do I tell the >compiler that in1 and

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 21:09 +, Kevin Chadwick wrote: > On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: > > > I was inquiring about the possibility of no identifiers or > > >

Re: [go-nuts] Generics syntax suggestion

I think the question was: "given your proposal here, I can write func (string | []byte in1, string | []byte in2) which enforces that in1 and in2 must be either of type string or type []byte, but how do I tell the compiler that in1 and in2 must be of the *same type* (whether it is string or []byte)

Re: [go-nuts] Generics syntax suggestion

On January 19, 2021 8:22:01 PM UTC, 'Dan Kortschak' via golang-nuts wrote: >On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: >> I was inquiring about the possibility of no identifiers or >> abstraction but simply like Gos non generic functions (possibly >> reversed if needed). Using type

Re: [go-nuts] Generics syntax suggestion

On Tue, 2021-01-19 at 20:01 +, Kevin Chadwick wrote: > I was inquiring about the possibility of no identifiers or > abstraction but simply like Gos non generic functions (possibly > reversed if needed). Using type OR type. > > func (String | []byte firstInput, myType | publicKey > secondInput)

Re: [go-nuts] Generics syntax suggestion

How would you express the equivalent of func Min[T constraints.Ordered](a []T) T { min := a[0] for _, v := range a[1:] { if v < min { min = v } } return min } using this syntax? More generally, it is probably useful to go through the examples from the d

[go-nuts] Generics syntax suggestion

>> Seems to me that most generics implementations use a capital letter >> abstracted type syntax that I hate. >> > >This is just a convention and not part of the syntax, which means it's >irrelevant to the discussion about the proposal. You can easily use >lowercase letters/identifiers: >https

Re: [go-nuts] Generics security discussion.

On Wed, Jan 13, 2021 at 6:38 AM Kevin Chadwick wrote: > > On 1/13/21 2:09 PM, Axel Wagner wrote: > > Let me repeat my question: Do you have any concrete reason to assume there > > is a > > negative security impact of generics? Feel free to bring that up. > > Otherwise, I > > don't see a reason t

Re: [go-nuts] Generics security discussion.

On Wed, Jan 13, 2021 at 3:38 PM Kevin Chadwick wrote: > I don't and I don't mean to make demands of other peoples time. Though I'm > sure > security has been carefully considered and might be fresh in peoples minds. I don't think it has, because I don't think it needs to be. There is no reason

Re: [go-nuts] Generics security discussion.

I covered the DoS. There are multitude of ways to create DoS even in “correct” code, panics are just one example. Memory corruption is a different class of security bug because it allows arbitrary code execution. > On Jan 13, 2021, at 8:20 AM, Kevin Chadwick wrote: > > On 1/13/21 2:06 PM,

Re: [go-nuts] Generics security discussion.

On 1/13/21 2:09 PM, Axel Wagner wrote: > Let me repeat my question: Do you have any concrete reason to assume there is > a > negative security impact of generics? Feel free to bring that up. Otherwise, I > don't see a reason to talk about it in the design doc. I don't and I don't mean to make dem

Re: [go-nuts] Generics security discussion.

On 1/13/21 2:06 PM, Robert Engels wrote: > A panic is not a security issue. Memory corruption/stack overflow is. In Go > the latter is accomplished through CGo and unsafe pointers/operations. > It isn't as clear cut as that. Panics can be security issues and memory corruption/stack overflows ca

Re: [go-nuts] Generics security discussion.

On Wed, Jan 13, 2021 at 2:59 PM Kevin Chadwick wrote: > Clearly Go without interfaces, especially an empty interface is safer. > Perhaps > Generics reduce that risk via constraints etc.? > I understand why you might argue interfaces make the language less safe. But generics are a mechanism with

Re: [go-nuts] Generics security discussion.

A panic is not a security issue. Memory corruption/stack overflow is. In Go the latter is accomplished through CGo and unsafe pointers/operations. Continuous panics can be considered a security issue as a DoS attack but IMO at least there are many ways to generate continuous errors that are sim

Re: [go-nuts] Generics security discussion.

On 1/13/21 11:17 AM, Axel Wagner wrote: > Assuming generics like interfaces, potentially erode type safety. > > > Can you elaborate? Because that statement seems exactly contrary to > established > wisdom. Clearly Go without interfaces, especially an empty interface is safer. Perhaps Generi

Re: [go-nuts] Generics security discussion.

On Wed, Jan 13, 2021 at 11:54 AM Kevin Chadwick wrote: > I appreciate that generics use will be optional. However I am concerned > that neither in the design draft nor the proposal issue, that the word > security nor safety has been used even once. "Safety" has been mentioned lots of times, in

[go-nuts] Generics security discussion.

I appreciate that generics use will be optional. However I am concerned that neither in the design draft nor the proposal issue, that the word security nor safety has been used even once. Assuming generics like interfaces, potentially erode type safety. Will generics increase the likelihood of

  1   2   3   4   5   6   7   8   9   >