Request for review: proposal for @FunctionalInterface checking

[Brian Goetz]

In Doug's "tyranny of function names", there was an appeal for a known, 
regularized naming convention:

>  Using anything other than a known regularized naming scheme
> in libraries will make it impossible to ever take advantage of
> language-based function type support.

Perhaps @FunctionalInterface can be extended to provide this.  Instead 
of just

@FunctionalInterface
interface Predicate<T> { ... }

the annotation could capture the parameter and return types as well:

@FunctionalInterface(return = boolean.class,
                      params = { Object.class })
interface Predicate<T> { ... }

(or better, some scheme that lets us encode generic signatures rather 
than erased ones).

Then we're making a clear statement that "Predicate<T> is a functional 
interface with type signature T->boolean", which would open the door to 
future loosenings in a less ad-hoc way?

Doug, does this help at all?

On 12/28/2012 3:02 PM, Joe Darcy wrote:
> Hello,
>
> We've had some discussions internally at Oracle about adding a
> FunctionalInterface annotation type to the platform and we'd now like to
> get the expert group's evaluation and feedback on the proposal.
>
> Just as the java.lang.Override annotation type allows compile-time
> checking of programmer intent to override a method, the goal for the
> FunctionalInterface annotation type is to enable analogous compile-time
> checking of whether or not an interface type is functional.  Draft
> specification:
>
> package java.lang;
>
> /**
> Indicates that an interface type declaration is intended to be a
> <i>functional interface</i> as defined by the Java Language
> Specification.  Conceptually, a functional interface has exactly one
> abstract method.  Since default methods are not abstract, any default
> methods declared in an interface do not contribute to its abstract
> method count.  If an interface declares a method overriding one of the
> public methods of java.lang.Object, that also does <em>not</em> count
> toward the abstract method count.
>
> Note that instances of functional interfaces can be created with lambda
> expressions, method references, or constructor references.
>
> If a type is annotated with this annotation type, compilers are required
> to generate an error message unless:
>
> <ul>
> <li> The type is an interface type and not an annotation type, enum, or
> class.
> <li> The annotated type satisfies the requirements of a functional
> interface.
> </ul>
>
> @jls 9.8 Functional Interfaces
> @jls 9.4.3 Interface Method Body
> @jls 9.6.3.8 FunctionalInterface  [Interfaces in the java.lang package
> get a corresponding JLS section]
> @since 1.8
> */
> @Documented
> @Retention(RUNTIME)
> @Target(TYPE)
> @interface FunctionalInterface {} // Marker annotation
>
> Annotations on interfaces are *not* inherited, which is the proper
> semantics in this case.  A subinterface of a functional interface can
> add methods and thus not itself be functional.  There are some
> subtleties to the definition of a functional interface, but I thought
> that including those by reference to the JLS was sufficient and putting
> in all the details would be more likely to confuse than clarify.
>
> Please send comments by January 4, 2013; thanks,
>
> -Joe
>