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

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

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

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

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

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

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.

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

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/

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

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.

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

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

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

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

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

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

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

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

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

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

Re: [go-nuts] Generics and formatting

If I understand right the panic is because the `m := NewMap[string, int]` is a function not a function call and after that you try to assign to this function `m[int]`. This works https://go2goplay.golang.org/p/NOaPH-dJyWd . On Tue, 2021-01-05 at 08:10 -0800, Brian Candler wrote: > I don't know if t

Re: [go-nuts] Generics and formatting

On 06/01/2021 21:52, Ivan Majeru wrote: If I understand right the panic is because the `m := NewMap[string, int]` is a function not a function call and after that you try to assign to this function `m[int]`. This works https://go2goplay.golang.org/p/NOaPH-dJyWd

Re: [go-nuts] Generics and constraints question

On Tuesday, 5 January 2021 at 20:27:57 UTC rog wrote: > You can do this with type-list interfaces: > https://go2goplay.golang.org/p/wfHnVHOMcyK > > This is one of the harder parts of the proposal to understand IMHO, but > perhaps it will become easier with familiarity. > Thank you! -- You re

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

On Tue, Jan 5, 2021 at 7:25 PM tapi...@gmail.com wrote: > On Tuesday, January 5, 2021 at 8:43:44 AM UTC-5 axel.wa...@googlemail.com > wrote: > >> On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan >> wrote: >> >>> Why does there need to be a delimiter, there isn't one between chan and >>> int in

Re: [go-nuts] Generics and formatting

On Tue, Jan 5, 2021 at 8:11 AM Brian Candler wrote: > > I don't know if this is expected, but this (bad) program causes the go2go > playground to give "panic: assertion failed" > > https://go2goplay.golang.org/p/VH5SLJNxw3X > > - I think it's the compiler itself that's panicing, not the runtime (

Re: [go-nuts] Generics and constraints question

This definitely needs a better error message. Ian On Tue, Jan 5, 2021 at 12:27 PM roger peppe wrote: > > You can do this with type-list interfaces: > https://go2goplay.golang.org/p/wfHnVHOMcyK > > This is one of the harder parts of the proposal to understand IMHO, but > perhaps it will become

Re: [go-nuts] Generics and constraints question

You can do this with type-list interfaces: https://go2goplay.golang.org/p/wfHnVHOMcyK This is one of the harder parts of the proposal to understand IMHO, but perhaps it will become easier with familiarity. On Tue, 5 Jan 2021, 17:32 Brian Candler, wrote: > Question: how to make a generic functio

Re: [go-nuts] Generics and formatting

Here's another unhelpful error: https://go2goplay.golang.org/p/GDxiXiIIti7 Error: "prog.go2:7:11: all type parameters must be named" Actual problem: the type parameters *were* named, but no constraint was given. func blah[T1, T2](x T1) T2 { // wrong func blah[T1, T2 any](x T1) T2 { // fixed

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

On Tuesday, January 5, 2021 at 8:43:44 AM UTC-5 axel.wa...@googlemail.com wrote: > On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan > wrote: > >> Why does there need to be a delimiter, there isn't one between chan and >> int in chan int, which I think is more readable than chan[int]. >> > >

Re: [go-nuts] Generics and formatting

I don't know if this is expected, but this (bad) program causes the go2go playground to give "panic: assertion failed" https://go2goplay.golang.org/p/VH5SLJNxw3X - I think it's the compiler itself that's panicing, not the runtime (since it doesn't get as far as the next line). Aside: my

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan wrote: > Why does there need to be a delimiter, there isn't one between chan and > int in chan int, which I think is more readable than chan[int]. > `chan` is a keyword, names of generic types and functions are identifiers. So, in a way, yes, the

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

There is a delimiter in 'chan int' -> ' ' (space) I don't think it is a good assumption that "most generic types would only have 1 type-parameter" (or 2, or 3, or any other arbitrary number for what it's worth). Moreover, I don't think it is a good idea to assimilate builtin language constructs to

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

Axel, please send your reply to golang-nuts too, you can ignore the rest of this, I already sent it to you but not golang-nuts because I didn't reply to all. > What is the "them" to be omitted if there is only one type parameter? It > wouldn't make sense to omit the brackets (because there need

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

On Monday, January 4, 2021 at 5:23:06 PM UTC-5 ren...@ix.netcom.com wrote: > Reading > > sync.Map[string]linked.List string > > I have no idea what that represents? > If you can read sync.Map[string]chan string then you can read "sync.Map[string]linked.List string" too. > > What if

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

Reading sync.Map[string]linked.List string I have no idea what that represents? What if you had a map of maps - which is a very common data structure - possibly with completely different key and value types? Really any nested data structures with multiple types would be impossible to read IMO.

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

What is the "them" to be omitted if there is only one type parameter? It wouldn't make sense to omit the brackets (because there needs to be some delimiter between the name of the generic function/type and the type argument). But if there is only one type-parameter anyway, I don't know what else yo

Re: [go-nuts] Generics - please provide real life problems

I posted two real world problems where Generics would be useful to me, earlier in the thread. Saw no response, and now continued claims that no real world problems have been provided? I'm not sure if that is disingenuous, or merely an artifact of the client someone is using causing replies that

Re: [go-nuts] Generics - please provide real life problems

On Mon, Jan 4, 2021 at 9:20 AM Volker Dobler wrote: > On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote: > >> I do believe (hope) David was kidding. Anonymous product types (and >> similar constructs) are the root of all evil. >> > > Yes, you need dependent product types. Esp

Re: [go-nuts] Generics - please provide real life problems

On Sun, Jan 3, 2021 at 6:32 PM roger peppe wrote: > FWIW I'm certain that the lack of tuples in Go was a very deliberate > decision - one of Go's more significant ancestors, Limbo, had tuples. > Anonymous product types have their disadvantages too (you don't get to > name the members, so code can

Re: [go-nuts] Generics - please provide real life problems

On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote: > I do believe (hope) David was kidding. Anonymous product types (and > similar constructs) are the root of all evil. > Yes, you need dependent product types. Especially anonymous ones. (Just be be clear: I _am_ kidding.) V

Re: [go-nuts] Generics - please provide real life problems

I do believe (hope) David was kidding. Anonymous product types (and similar constructs) are the root of all evil. > On Jan 3, 2021, at 11:32 AM, roger peppe wrote: > > FWIW I'm certain that the lack of tuples in Go was a very deliberate decision > - one of Go's more significant ancestors, Limb

Re: [go-nuts] Generics - please provide real life problems

FWIW I'm certain that the lack of tuples in Go was a very deliberate decision - one of Go's more significant ancestors, Limbo, had tuples. Anonymous product types have their disadvantages too (you don't get to name the members, so code can end up significantly harder to understand), which I suspect

Re: [go-nuts] Generics - please provide real life problems

On Thu, Dec 31, 2020 at 9:45 PM da...@suarezhouse.net wrote: > Real use cases have been provided it appears for both why generics can be > good and how they can be used negligently (love the sextuple example BTW). Some future language will invent the idea that you should be able to create anony

Re: [go-nuts] Generics and formatting

On Sat, Jan 2, 2021 at 10:28 AM 'Brian Candler' via golang-nuts wrote: > > Raised as https://github.com/golang/go/issues/43470 Thanks. Ian > On Friday, 1 January 2021 at 18:40:36 UTC Ian Lance Taylor wrote: >> >> On Fri, Jan 1, 2021 at 9:50 AM 'Brian Candler' via golang-nuts >> wrote: >> > >

Re: [go-nuts] Generics and formatting

Raised as https://github.com/golang/go/issues/43470 On Friday, 1 January 2021 at 18:40:36 UTC Ian Lance Taylor wrote: > On Fri, Jan 1, 2021 at 9:50 AM 'Brian Candler' via golang-nuts > wrote: > > > > Just a minor issue, but playing with this example: > > https://go2goplay.golang.org/p/IUL1QDrtOw

Re: [go-nuts] Generics Error - How to fix?

Thank you!  My personal opinion from this small journey into this topic is what you all built here is very flexible and robust.  Are you all at the point of "perfect is the enemy of the good"?  What is the criteria that will define when this releases? As I see it, if

Re: [go-nuts] Generics - please provide real life problems

Thinking about this some more, I am not sure it is viable. Important operations, like “putIfAbsent” would not be possible with the current Go map syntax. That being said, many of the Java collections interfaces declare “optional” methods, and I guess that could be used here. It would be easy to

  1   2   3   4   5   6   7   8   >