Primitives in Generics

[Pavel Minaev]

On Fri, Jul 9, 2010 at 4:31 PM, Neal Gafter <neal at gafter.com> wrote:
> On Fri, Jul 9, 2010 at 4:18 PM, Pavel Minaev <int19h at gmail.com> wrote:
>>
>> We have already established that neither proposed Java nor C# lambdas
>> have function types per se, but obtain them via target-typing. So your
>> claim then boils down to "SAMs are not function types". And why aren't
>> they? Why shouldn't C# delegate types rather be treated as mere
>> syntactic sugar for a single-method interface or abstract class?
>
> Are you proposing a language change for C#?  If it would introduce into C#
> all of the disadvantages of project lambda's specification, I don't think
> that would be worth doing.

No, I'm asking what is the practical difference between a delegate
type and a single-method interface, in the context of function types.

>> >> So far as I can see, C# has precisely the same limitations here as the
>> >> proposed no-function-types-but-SAM-conversion for Java.
>> >
>> > C# lambdas bind names lexically.  The proposed lambdas do not.
>>
>> Do you mean SAM type members?
>
> I don't understand your question.  I'm referring to the binding of free
> names appearing in a lambda expression, which in the proposal are first
> sought in the scope of the target type (i.e. not lexically).

That is what I meant. In the typical case of a single-method interface
(which would directly correspond to C# delegates; anything above that
is "extra" on Java side), we're talking about a single name here that
will be found in that scope. Again this seems to be a fairly minor
issue - and it has a positive side effect of enabling self-recursive
lambdas without the need to pass the lambda to itself as an argument.

>> > C# "function types" (delegates) are typically defined to be covariant in
>> > return types and contravariant in argument types.  SAMs cannot be so
>> > defined.
>>
>> That boils down to declaration-site variance in C# vs use-site
>> variance in Java. SAMs cannot be so defined, but nothing prevents you
>> from using wildcards when referencing them to achieve the same effect.
>
> Nothing prevents you from programming in assembly language either.  It isn't
> very practical to expect programmers to do so correctly or consistently; the
> purpose of a programming language extension is to make things easier for the
> programmer, not harder.

Perhaps, but, again, this should be an argument for declaration-site
variance for generics in general, and not just for function types.

>> > C#'s generic delegate types such as Func<Arg,Return> can specialize over
>> > primitives and over different numbers of arguments.  SAMs cannot.
>>
>> That is a separate problem which is also much broader, and should be
>> solved as such (i.e. reify generics, then you get that for function
>> types for free - any other solution is going to be partial, anyway).
>
> This has nothing to do with reification.  BGGA addresses the issue with its
> function types but does not reify.

I was under the impression that you need reification to make it
properly work for generics _in general_ (and I am quite possibly wrong
here, so please correct me if I am).

Regardless, the point is that once you make it work for generics in
general, it also applies to SAM types under the current proposal - and
the utility of such a solution would be far greater. On the other
hand, enabling primitives for function types while leaving the same
limitations for generics would definitely lead to the question of "why
did they solve that problem for the new thing, but didn't also fix it
for the old one?".