A couple of questions on (a) type promotion to interfaces (b) variadic functions

[Sanjay]

Just curious about these language decisions. Would appreciate some insight?

1. The compiler will happily promote a type to an interface when necessary - but not for arrays. Tell me if I am wrong, but interfaces seem to get used a lot for rudimentary polymorphism (i.e. to accept polymorphic types with the same interface). It seems natural to want to extend this to arrays of such types. But the compiler won't promote the entire array of types to interfaces. Any reason why it will do a lone type, and not an array of types?
   
   
2. A variadic function, for a type marked with "...", will accept (a) zero or more arguments of that type, or (b) a slice of that type - but not a mix of the two. I suppose there is a good reason for this. I'd like to know.
   
   

       func foo(arg0 int, argN ...string) string // SIGNATURE
   
       foo(1, "a", "b", "c") // OK
   
       foo(1, []string{"a", "b", "c"}...) // OK
   
       foo(1, "a", []string{"b", "c"}...) // NOT OK

   
   http://play.golang.org/p/CeHUc5XOCQ
   

[Volker Dobler]

Am Samstag, 3. Oktober 2015 14:51:42 UTC+2 schrieb Sanjay:

Just curious about these language decisions. Would appreciate some insight?

1. The compiler will happily promote a type to an interface when necessary - but not for arrays. Tell me if I am wrong, but interfaces seem to get used a lot for rudimentary polymorphism (i.e. to accept polymorphic types with the same interface). It seems natural to want to extend this to arrays of such types. But the compiler won't promote the entire array of types to interfaces. Any reason why it will do a lone type, and not an array of types?
   

The memory layout is different. This has been discussed

quite some times on this list, I'm sure you'll find plenty

infos on this topic. It boils down to: It cannot be done

(different memory layout) without some hidden (i.e. not

explicit) overhead; hidden is bad.  

1. A variadic function, for a type marked with "...", will accept (a) zero or more arguments of that type, or (b) a slice of that type - but not a mix of the two. I suppose there is a good reason for this. I'd like to know.
   
   

       func foo(arg0 int, argN ...string) string // SIGNATURE
   
       foo(1, "a", "b", "c") // OK
   
       foo(1, []string{"a", "b", "c"}...) // OK
   
       foo(1, "a", []string{"b", "c"}...) // NOT OK

   
   http://play.golang.org/p/CeHUc5XOCQ
   

No idea, but this seems pretty academic. Maybe: If it is

not used in practice, there is no need to support it,

"just because!"-

V. 

[Egon]

AFAICR, it's the same reason as 1.

foo(1, "a", "b", "c"), is simply equivalent to

foo(1, []string{"a", "b", "c"}...)

just syntax sugar... under the hood it will use []string as a parameter.

However,

foo(1, "a", []string{"b", "c"}...)

this would need to create an additional

foo(1, append([]string{"a"}, []string{"b", "c"}...))

To make it work, hence it would be an hidden cost -- i.e. not allowed.

+ Egon