Function parameter order

[David Holmes]

On 9/11/2012 1:50 AM, Brian Goetz wrote:
>> I don't particularly like MapperInt either but I'll put up with it to
>> keep the type arguments in the expected order. (Though MapperToInt is
>> undoubtedly better still).
>
> And what about when more than one parameter is being specialized? The
> scheme should work for that too. (As Doug points out, this limits us to
> specializing an initial segment of parameters and not a single
> non-leading one.)

I don't understand your point here. I didn't invent a scheme, I used 
your scheme. Your scheme says that the placement of the specialization 
indicates which type parameter is being specialized. I simply stated 
that it is better to have the Return Type type parameter be last. This 
scheme handles first and last parameters easily and doesn't readily 
handle anything else.

>> These specializations are a workaround for a lack of decent primitive
>> type support, so their naming should not be the major decision criteria
>> when designing the API.
>
> I think this would be abdicating our responsibility. We're the ones
> foisting this nominal scheme on the users. We have good reasons for
> doing so (e.g., structural function types interact awfully with erasure
> and maybe also with boxing), but since we have to replace it with
> something, it should be as good as we can make it. And that means
> including the specializations as first-class considerations in the
> design discussion, not nailing them on afterwards.

I said "not the major decision criteria". I did not say it was not 
first-class, nor that it should nailed on afterwards. But a stylistic 
preference to IntMapper over MapperInt is not reason enough to change 
common usage and put the Return Type parameter first.

David