On Sun, 21 Oct 2018 at 13:40, Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe <rogpe...@gmail.com> wrote:
>
>> Yes. The draft proposal says "generic functions, rather than generic
>> types, can probably be compiled using an interface-based approach. That
>> will optimize compile time, in that the package is only compiled once, but
>> there will be some run-time cost.". I don't think this is possible as
>> stated. I don't even know what it means to compile a generic type, as types
>> themselves aren't compiled - unless they're talking about compiling methods
>> on generic types, in which case I don't see how they differ from generic
>> functions.
>>
>> I do believe it's possible to avoid generating code for every possible
>> set of type parameters to a generic function. There's a continuum of
>> efficiency. At one end, we *could* generate code for each possible set of
>> type parameters (giving efficient code but binary bloat), and at the other,
>> I think it's possible to generate a function containing reflect-based code
>> that will work on all possible type parameters (*) but is comparatively
>> very slow.
>>
>
> To me, it seems that you are contradicting yourself here. To clarify: To
> me, an "interface-based approach" and "reflect-based code" essentially
> comes down to exactly the same thing: We pass run-time type information to
> the function which then unpacks that to do the actual work. Tomato Potahto
> ;)
>
The two approaches are quite different in their runtime implications. Using
reflect to make function calls is a couple of orders of magnitude slower
than calling interface methods directly.
(and FWIW "compiling a type", I believe, refers to generating a
> reflect.rtype/runtime._type at compile time and embedding it in the binary.
> So, if you have `type Foo(T) struct { x T }`, an interface-based
> compilation would just generate one run-time type of the form `type Foo
> struct { x interface{} }`, whereas a static approach would create e.g.
> `type Foo(int) struct { x int }`, `type Foo(string) struct { x string }`,
> etc)
>
> But, I guess, I'm fine to agree to disagree at that point then - if you
> think a purely run-time/reflect/interface/… approach is impossible, I can't
> argue with that :)
>
Yeah, I don't believe that's possible. Because then you couldn't have a
*Foo(byte) pointing into the middle of a slice of `struct {x byte}` values.
>
--
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.
