>> 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
>> 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
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
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
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
>> 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()
>> 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
>> 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
>> 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
>> 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
>> 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
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
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
>> 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
19 matches
Mail list logo