Perhaps a better question is: Given a generic function
func Get(l List<E>, i int) E {
…
}
var a List<int>{ 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))
// Should print "1 2 3.0"
implement the code, a compiler would generate for this, in C (or, if you
prefer, the current, real, go. But C is probably better). This is the best
way to illustrate, how you envision it to work. Only then can we actually
talk about what you are proposing here.
On Fri, Jul 1, 2016 at 9:17 PM, Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> You are still not making a clear decision about the generics dilemma here.
>
> On Fri, Jul 1, 2016 at 8:59 PM, Andrew Mezoni <andrew.mez...@gmail.com>
> wrote:
>
>> >> Go has to run in environments where runtime code-generation /
>> modification is not allowed.
>>
>> Where you find that I wrote about that?
>> The generic code (not a parametrized code) executed in the same manner as
>> the reflection works.
>>
>
> That is the java way. You basically take a separate size argument.
>
>
>> But with a single and very big differnce.
>> The reflection is slow because it designed to be "for all occasions".
>> The generic code are:
>> - Analysed by the compiler
>> - Optimised by the compiler
>> - Unnecessary code eliminated by the compiler (maximally reduced some
>> procedures to minimal overhead)
>>
>
> This is the C++ way. You have a specialization per type.
>
> This is a main reason why the compiled generic code (not a parametrized
>> code) in the most cases not a much more slower than a non-generic code (but
>> not always).
>>
>
> You either are choosing the java way, which slows down execution, or the
> C++ way, which slows down compilation (or you try, like you currently are,
> to walk around it by claiming you are doing some kind of mix, which would
> be fine, but it wouldn't eliminate those disadvantages, the parts you are
> doing the java way are slow to execute and the parts you are doing the c++
> way are slow to compile).
>
>
>>
>> P.S.
>>
>> Seriously, where you found that I wrote something about the requirements
>> of the "runtime code-generation / modification" in my examples?
>> Yes, my English is terrible but I never did not mention these notions.
>>
>> --
>> 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.
>>
>
>
--
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.
