Function parameter order

[Brian Goetz]

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

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