On Fri, Jul 1, 2016 at 10:00 PM, Andrew Mezoni <andrew.mez...@gmail.com>
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 that doesn't make it
the wrong question. And it doesn't mean, a proposal for generics doesn't
need to be able to answer them.
> They return pointers to appropriate values.
>
Or you really think that the `map` also returns a value instead of pointer?
>
Yes, it does. It returns essentially a struct, which then contains
pointers, to memory with well-known at compile time sizes. 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. A function doesn't
return a map[S]T, it returns a map[int]string and thus it knows that every
bucket of that map must contain a word for the int and two words for the
string.
> How it (map) can know the size of the return value
> The `map` in Go language also generic type.
>
No, it's not. Again, there is no map[S]T. It's a fabrication. Every map has
a concrete, specific, compile-time known type. Every function that uses a
map knows the exact type of both key and value, so there is no problem here.
If you are proposing to generalize map, what you are really proposing, is
the C++ way, because that's essentially what go is doing (just that the
compiler knows very well what the concrete behaviors of the type are and
that it can inline some parts that are appropriate and use generic versions
in other places, where it isn't. It can't do that for actual generic types).
I'll repeat the question: Your proposal needs to be able to compile this
(or equivalent) code to C (or assembler, or go, or something specific
enough that we can talk about what it is actually doing):
func Get(l List<E>, i int) E {
…
}
var a List<int64>{ 1, 2, 3 }
var b List<string>{ "1", "2", "3" }
var c List<float64>{ 1.0, 2.0, 3.0 }
fmt.Println(Get(a, 0), Get(b, 1), Get(c, 2))
as it needs to be able to compile this (or something equivalent) to
something specific, make us understand what you are proposing, by providing
what this compiles to. For example, write a go program, which accurately
reflects, what this is supposed to do, which is a) valid with the current
semantics of go, e.g. runs on the playground) and b) prints "1 2 3.0". You
may change the generic input, but it needs to maintain the invariant that
it only contains one implementation of the Get function.
It doesn't make sense to continue a discussion where you are continuing to
handwave your way around the questions. The good thing about this last
specific question is, that a valid proposal of how to handle generics must
be able to answer it, while at the same time, it is impossible to handwave
your way around it.
--
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 https://groups.google.com/d/optout.
