Primitives in Generics

[Neal Gafter]

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.


>  >> 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).


> > 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.


>  > 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.