Function parameter order (original) (raw)

David Holmes david.holmes at oracle.com
Thu Nov 8 19:20:53 PST 2012

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

More information about the lambda-libs-spec-observers mailing list