Function parameter order (original) (raw)

Brian Goetz brian.goetz at oracle.com
Thu Nov 8 07:50:36 PST 2012

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.

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