[go-nuts] Re: A proposal for generic in go

Lol, Doug Cheney. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit

[go-nuts] Re: A proposal for generic in go

On Saturday, July 2, 2016 at 9:12:54 AM UTC-4, Chad wrote: > > > > The appeal of generics is probably a false appeal. > > Then, if you accept the trilemma described at http://research.swtch.com/generic, that puts you in favor of "slow programmers"... just kidding. I went back to read all the

[go-nuts] Re: A proposal for generic in go

What's generic programming? An implementation of overloading for datastructures and function/methods. The compiler is left in charge of going through the code and specifying which types should actually be used. Go restricts the overloading of function/methods. So we are left with the

Re: [go-nuts] Re: A proposal for generic in go

>> I would also like to point out again that I am not arguing in favor or against the C++ or the Java way. I am simply trying to get you to answer the question which of the two you are proposing. Neither one nor the other. Only the "Go way". And I am did not propose. I am only try bring

Re: [go-nuts] Re: A proposal for generic in go

>> That there is an indirection in the struct doesn't mean that a function doesn't need to know the size of the memory it is allocating for a bucket. Your judgement are now incorrect. Obtaining the size of the of the type is not so hard at runtime. It always known from `rtype` This is how map

Re: [go-nuts] Re: A proposal for generic in go

On Fri, Jul 1, 2016 at 10:00 PM, Andrew Mezoni wrote: > >> How does the generic function know the size of the return value? > > All your judgement are not correct only because you ask not a correct > questions. > I am not asking the questions you want me to ask, but

Re: [go-nuts] Re: A proposal for generic in go

Can I ask the question out of turn? Ok. I ask. What wrong in Java way? What wrong in C# way? Of course, they have a boxing/unboxing concepts. Does this means that boxing/unboxing is very, very, very slow operations and should not be used even in Java or in C#? But they used. They used at least in

Re: [go-nuts] Re: A proposal for generic in go

On Fri, Jul 1, 2016 at 9:51 PM, wrote: > > How does the compiler know sizeof(T)? >> > > > interesting question. About obtaining sizeof(T). The sizeof(T) is known > from the call site calling the generic function, in particular from the > type of variable that's passed to

Re: [go-nuts] Re: A proposal for generic in go

>> How does the generic function know the size of the return value? All your judgement are not correct only because you ask not a correct questions. They return pointers to appropriate values. Or you really think that the `map` also returns a value instead of pointer? How it (map) can know the

Re: [go-nuts] Re: A proposal for generic in go

On Fri, Jul 1, 2016 at 12:51 PM, wrote: > > Perhaps modify Golang's 2.0 calling convention, that EVERY function must get > upon compilation one extra invisible-to programmer argument that is pointer > that > when said function is generic, points to sizeof(T) storage place .

Re: [go-nuts] Re: A proposal for generic in go

> How does the compiler know sizeof(T)? > interesting question. About obtaining sizeof(T). The sizeof(T) is known from the call site calling the generic function, in particular from the type of variable that's passed to the generic function. What If generic function calls another generic

Re: [go-nuts] Re: A proposal for generic in go

Perhaps a better question is: Given a generic function func Get(l List, i int) E { … } var a List{ 1,2,3} var b List{"1", "2", "3"} var c List{1.0, 2.0, 3.0} fmt.Println(Get(a, 0), Get(b, 1), Get(c, 2)) // Should print "1 2 3.0" implement the code, a compiler would generate for this, in C

Re: [go-nuts] Re: A proposal for generic in go

On Fri, Jul 1, 2016 at 12:40 PM, wrote: > the parametrized struct got me interested, how to best handle the > embedding the arbitrary type. > > Especially passing said struct to a generic function. > > > > type S struct { > > I1 int > > C1 char > > *T1 T* > > I2 int > >

[go-nuts] Re: A proposal for generic in go

>> I believe you've made a mistake here, elem needs to be *T , not T This was just an abstract example. I just wanted to say that if someone want to try implement a transpiller of the "Go.next" to the "Go" then the better way to represent the data of the different types (which are specified by

[go-nuts] Re: A proposal for generic in go

On Friday, July 1, 2016 at 1:53:46 PM UTC+2, Andrew Mezoni wrote: > > >> Now imagine that T=int8 > > Generic struct always has the same size only because it uses pointers. > > type S struct { > elem ***T > arr []T > } > > I believe you've made a mistake here, elem needs to be *T , not T --

[go-nuts] Re: A proposal for generic in go

>> Now imagine that T=int8 Generic struct always has the same size only because it uses pointers. type S struct { elem T arr []T } Is the same as the following struct. type S struct { elem unsafe.Pointer arr []unsafe.Pointer } This is because it is designed to be universal. You may

[go-nuts] Re: A proposal for generic in go

On Wednesday, June 15, 2016 at 3:04:05 AM UTC+2, xingtao zhao wrote: > > Here is my proposal for generic in go: > https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing > > Many parts has not been finished, and just initial thoughts. In the > proposal,

Re: [go-nuts] Re: A proposal for generic in go

torsdag 30. juni 2016 18.04.13 UTC+2 skrev charr...@gmail.com følgende: > > > > On Wednesday, June 29, 2016 at 3:42:51 PM UTC+2, Øyvind Teig wrote: >> >> The suggestions of generics discussed here and in the referenced >> documentation, will it be possible to compile the "Go-with-generics" >>

Re: [go-nuts] Re: A proposal for generic in go

The suggestions of generics discussed here and in the referenced documentation, will it be possible to compile the "Go-with-generics" language into some idiomatic Go and compile it with the standard compiler? (I guess *what* idiomatic means is the real question here..). Or would it break

[go-nuts] Re: A proposal for generic in go

On Wednesday, June 29, 2016 at 2:31:59 AM UTC-4, Egon wrote: > > Just to be clear what I consider a *great example* for analyzing generics: > > 2. 3+ real-world packages/applications use that package > * By real-world here I mean it wasn't written for learning or fun, but > rather solving a

[go-nuts] Re: A proposal for generic in go

On Wednesday, 29 June 2016 06:35:03 UTC+3, Egon wrote: > > On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote: >> >> Earlier someone asked about real world examples. The obvious standard >> library was mentioned. It only took me a few seconds to remember Jan >> Mercl's interval package.

[go-nuts] Re: A proposal for generic in go

On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote: > > Earlier someone asked about real world examples. The obvious standard > library was mentioned. It only took me a few seconds to remember Jan > Mercl's interval package. A quick look suggests that the current 1200+ > lines of code

Re: [go-nuts] Re: A proposal for generic in go

Really? How would you implement math.Max with generics? Thomas On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov wrote: > https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are > just two stdlib packages that would greatly benefit from some kind of >

Re: [go-nuts] Re: A proposal for generic in go

>> The fact still remains that unlike a lot of other proposed languages additions that are immediately dropped, generics are still open for discussion by the language developers themselves. I think that the problerm only in the Go developers brcause them even does try to implement them

[go-nuts] Re: A proposal for generic in go

On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wrote: > You still haven't provided any argument why generics is indispensable. That can't be the litmus for language feature inclusion; if it was, Go would resemble ASM. In my personal experience, something North of 50% of my non-trivial

Re: [go-nuts] Re: A proposal for generic in go

On Wednesday, 22 June 2016 15:32:53 UTC+3, Andrew Mezoni wrote: > > >> The version without generics is necessary to compare how well a > particular generics approach improves the current language and code. > > I am sorry but this is obviously that any useful feature (in the context > of solving

Re: [go-nuts] Re: A proposal for generic in go

On Tuesday, June 21, 2016 at 9:56:01 PM UTC+3, Axel Wagner wrote: > > The issue is, that a "KeyValuePair" (no matter if you implemented it > via generics or like you mention via interfaces) is a fundamentally useless > type and generics encourage people to add useless types. A

Re: [go-nuts] Re: A proposal for generic in go

>> The version without generics is necessary to compare how well a particular generics approach improves the current language and code. I am sorry but this is obviously that any useful feature (in the context of solving problems) improves the current language and code. Another question: how new

Re: [go-nuts] Re: A proposal for generic in go

>> You are not bringing anything new to the table here, except the attempt to insult my intelligence, apparently. > > I do not have any claims to anyone personally. I only defend my own point of view. P.S. Also I don't love to see or use some (not my own) code which written like a mess. If I

Re: [go-nuts] Re: A proposal for generic in go

You are not bringing anything new to the table here, except the attempt to insult my intelligence, apparently. There are huge software projects out there written in languages that are less type safe than go and the vast majority of code written is not reusable. Both also aren't absolutes. There

Re: [go-nuts] Re: A proposal for generic in go

Sorry for typo and possible spam but correct example here: type Foo interface { Get(key K) V Set(key K, val V) } func foo() (int, Foo) { // Typo: foo := {} foo := {} // ... foos := []Foo{} // ... k := "London" // ... return

Re: [go-nuts] Re: A proposal for generic in go

And my point is and was: It doesn't *need* to be both type safe *and* reusable, unless you are focusing your energy on writing frameworks or treating type safety as a goal solely for it's own sake. It's perfectly fine to write small stuff yourself (for example like this) with explicit types and

Re: [go-nuts] Re: A proposal for generic in go

>> perfectly type safe. Perfectly type safe but not perfectly reusable. What If we slightly complicate the task? Now is my code and I want to see on your code exampe (perfectly type safe but and perfectly reusable) type Foo interface { Get(key K) V Set(key K, val V) } func foo()

[go-nuts] Re: A proposal for generic in go

I think I have to agree with most of the posters here about generics. In theory, I miss them. However, in practice, I find that there are usually only a few times during the course of a project where I wish I had generics. And then after writing a few lines of code to do what the generic

Re: [go-nuts] Re: A proposal for generic in go

The issue is, that a "KeyValuePair" (no matter if you implemented it via generics or like you mention via interfaces) is a fundamentally useless type and generics encourage people to add useless types. A "KeyValuePair" is a "struct { Key K, Value V }", plain and simple. It's not an

Re: [go-nuts] Re: A proposal for generic in go

>> What I mean is that most people who have followed the past generics discussions already know it's possible to implement them with efficient memory use and performance. So they don't need to worry much about that. Thank you for explanation. >> can they be implemented without making Go a

[go-nuts] Re: A proposal for generic in go

You still haven't provided any argument why generics is indispensable. The reason why I am no longer sure about my position in this issue is because -while I agree that generics is useful- I don't think that generics is essential. In fact, all of C++ features are useful and implemented in a

Re: [go-nuts] Re: A proposal for generic in go

On Tue, Jun 21, 2016, at 03:17 PM, andrew.mez...@gmail.com wrote: > >>increase in cognitive load to decipher chains of type definitions. > > Sorry, but who are members of this mail lists? > This is a first time when I hear about such loads such as the > `cognitive load`. > Also I am possible

Re: [go-nuts] Re: A proposal for generic in go

>> increase in cognitive load to decipher chains of type definitions. Sorry, but who are members of this mail lists? This is a first time when I hear about such loads such as the `cognitive load`. Also I am possible here a single person who does not know anything about the `cognitive load to

Re: [go-nuts] Re: A proposal for generic in go

On Tue, Jun 21, 2016, at 01:45 PM, andrew.mez...@gmail.com wrote: > >>I am not saying that generics is bad, but I am questioning whether > >>generics is necessary. > > Please, do not panic. > If you worry about the following things: > - Generated code will grow when used generics > - Generated

[go-nuts] Re: A proposal for generic in go

>> I am not saying that generics is bad, but I am questioning whether generics is necessary. Please, do not panic. If you worry about the following things: - Generated code will grow when used generics - Generated code will be more complex when used generics - Execution performance will slow

[go-nuts] Re: A proposal for generic in go

I am not saying that generics is bad, but I am questioning whether generics is necessary. On Tuesday, June 21, 2016 at 3:45:08 PM UTC+7, andrew...@gmail.com wrote: > >> I was one of the generics supporters for Go in this forum, but now I am > not so sure. > > But why? > Generic types is the

[go-nuts] Re: A proposal for generic in go

>> I was one of the generics supporters for Go in this forum, but now I am not so sure. But why? Generic types is the same types as and the regular types. Difference only in that the regular types does not have a parameters but generic types are always have at least one parameter. This is why

[go-nuts] Re: A proposal for generic in go

I think we should carefully consider whether generics is worthy enough to be added into the language. It is easy to add a feature, but nearly impossible to remove one without breaking the backward compatibility promise. One thing for sure is that we are in the middle of a paradigm shift. I am

[go-nuts] Re: A proposal for generic in go

>> While later I realized that we still need some parameter check in the callee code to satisfy the interface matching (the generic version of each function in my proposal). A am sorry but your judgements is not correct. Here is a proofs: 1. It is redundant to perform check of the correctness

[go-nuts] Re: A proposal for generic in go

Overhead at runtime will be not very big; 1. Generate each time an instance of specific generic type with arguments 2. Perform generic specific type checks before any kind of an assignements 1. The first overhead can be reduced (eleminated) by the static code generation of specified generic

[go-nuts] Re: A proposal for generic in go

As for me then everything is much more simple if Go language (as the starting point) will introduce a non-reified generics. Non reified generics does not requires a complex runtime support (static code which was generated by the compiler will be enough). Type checking of the type arguments