Primitives in Generics
neal at gafter.com
Fri Jul 9 16:31:25 PDT 2010
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.
More information about the lambda-dev