Community
Participate
Working Groups
(1) 0.6.1, 15.28 says: "It is a compile-time error if the ClassType of a constructor reference denotes a class that is an enum type or that is abstract. " While JLS7 15.9 in addition says: "It is a compile-time error if any of the type arguments used in a class instance creation expression are wildcard type arguments (§4.5.1)." So is the less restrictive version with constructor references intentional ? I don't see anything in the design/motivation section regarding this to determine if it is. I would like to use one definition of what can be instantiated unless the relaxation is deliberate. So, should the following program compile ? // --- interface I { X<?> zoo(int x, String p); } public class X<T> { X(int x, String p) {} I i = X<? extends String>::new; // will compile X<?> x = new X<? extends String>(); // will not compile. } I don't see a type safety issue here since the parameterization would have pass bounds check, only a consistency issue. (2) And since the production for ClassType (despite the name) cannot prune type variables and annotation types, should these also be called out as error scenarios ? (3) Should the (obvious) point about primary evaluating to base type being a forbidden scenario be mentioned ? (4) "The immediately enclosing instance of an inner class instance (15.9.2) must be provided for a constructor reference by a lexically enclosing instance of this (8.1.3). " Is this restrictive ? Can this be supplied at method invocation time or even via a primary from ? Implementable != useful and I don't have an assessment as to how useful practically it would be though. Again this is a consistency issue: the call to new Inner() can occur outside of the enclosing class in an entirely unrelated class as long as there an enclosing instance is available and the types are visible.
(In reply to comment #0) > (1) 0.6.1, 15.28 says: > > "It is a compile-time error if the ClassType of a constructor reference > denotes a class that is an enum type or that is abstract. " > > While JLS7 15.9 in addition says: > > "It is a compile-time error if any of the type arguments used in a class > instance > creation expression are wildcard type arguments (§4.5.1)." 0.6.2 is amended to say: "if a method reference has the form ClassType :: NonWildTypeArgumentsopt new, it is a compile-time error if any of the type arguments used in the ClassType are wildcard type arguments" > (2) And since the production for ClassType (despite the name) cannot prune > type variables and > annotation types, should these also be called out as error scenarios ? 0.6.2 is amended to say: "If a method reference has the form ClassType :: NonWildTypeArgumentsopt new, the ClassType must denote a class that is accessible (6.6) and is not an enum type and not abstract, or a compile-time error occurs." > (3) Should the (obvious) point about primary evaluating to base type being a > forbidden scenario > be mentioned ? 0.6.2 is amended to say: "It is a compile-time error if a method reference has the form ExpressionName :: NonWildTypeArgumentsopt Identifier or Primary :: NonWildTypeArgumentsopt Identifier, and the type of the ExpressionName or Primary is not a reference type." > (4) "The immediately enclosing instance of an inner class instance (15.9.2) > must be provided for a constructor reference by a lexically enclosing > instance of this (8.1.3). " > Is this restrictive ? Can this be supplied at method invocation time or even > via a primary from ? Implementable != useful and > I don't have an assessment as to how useful practically it would be though. Received clarification on this: This limitation is acknowledged as being designed in - as a trade off between usefulness and complexity. Eclipse behavior already conforms to 0.6.2. Resolving.
