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

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

>> 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

[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

>> 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

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

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

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

>> 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()

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

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

[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 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

>> 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

Re: [go-nuts] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

>> Keeping a a pointer in a uintptr as a "reference" to something is safe iff it will never be casted back to a pointer. I think this means that the safe case is useless. Storing any reference (read: address) of Go instance is unsafe because after when this operation ends then a stored address