Proposal: Elided type specification for initialized final value declarations.

[Mike Elliott]

See attached PDF for a prettier version, but here's the text:

Title:

Elided type specification for initialized final value declarations.

Author:

Mike Elliott – The Boeing Company

Overview:

The use of the final keyword in declaring an initialized value (since
it's final it's not really a “variable”) is superfluous as all
necessary type information is available from the right hand side of
the declaration.  Eliminating the type declaration will increase
expressive power as well as reduce visual clutter.  This feature
exists to some degree  in other languages – the with construct in
Modula 3 for example and the untyped constant declarations and
(somewhat exotic) use of renames clauses in Ada – where it has been
shown to be useful in the building of complex expressions

Examples:

	private final HashMap<String, SomeClass.InnerClass> map =
		new HashMap<String, SomeClass.InnerClass>();

	would become

	private final map = new HashMap<String, SomeClass.InnerClass>();

Since the type is completely determined by the expression on the right
side of the equals sign, the type declaration on the left side of the
equals sign is unnecessary and only adds visual clutter, making it
more difficult to pick out the important thing, the name of the value
being expressed.  And since the value can never be changed the runtime
determination of type, subtype, etc., is not an issue.

A visually long value building process such as

        final BufferedInputStream in =
	         new BufferedInputStream(
		        new FileInputStream( filename ));

is sometimes broken up into multiple declarations in order to keep the
line lengths manageable, especially if there are coding conventions
prohibiting physical lines which exceed 80 columns in order to
encourage greater readability.

       final FileInputStream fis = new FileInputStream( filename );
       final BufferedInputStream inStream = new BufferedInputStream( fis );

While this is semantically equivalent to the previous code, it avoids
unsightly line wraps.  However, this would be cleaner still if the
type declaration could be elided:

       final fileInput = new FileInputStream( filename );
       final bufferedIn = new BufferedInputStream( fileInput );

Note that locality of type expression is maintained.  The programmer
could still determine the type of the constant at the point of
declaration.

Details:

This proposal makes optional the use of the type declaration when
declaring final values with an initiailzer expression.  The grammar
would simply make this declaration optional which would break no
existing code and still leave the deliberate declaration of type in
this situation available if, for example, the programmer wished to use
it as a sort of inline documentation.  It can free up a substantial
amount of screen real estate in the case of long type declarations
which could be better used with a more expressive name for the
constant than would otherwise fit on the line.  Additionally it would
encourage a greater use of the final keyword which can only help the
compiler in code optimization efforts and provide greater clarity for
the maintainer.

The type system itself would not be impacted.  The only change in
compilation would be the necessity to look ahead to the value
declaration in order to determine the constant's type from the value
declartion rather than have it literally expressed immediately before
that value declaration.  No new byte codes would be necessary.

Since this feature introduces no new functionality, no testing changes
would be introduced other than to confirm that eliding the type
declaration produces no changes in generated byte code.

No library support is needed, nor would there be any changes to the
reflection APIs.  There is no effect on JNI or serialization.

There would be an impact on JavaDoc as the type of the constant would
not be immediately obvious to a post-process tool if this feature is
allowed (as it probably should be) for named value declarations
outside of method declarations; that is, for other than “auto class”
declarations.

Compatability:

No previously existing valid programs would become invalid.  No
overloadings can occur other than those which already occur, such as
when a class variable in a superclass is “overloaded” by creating the
same class variable in a subclass (which should never have been
allowed anyway, but that's another story).

References:

	No known bugs related to this proposal.

-- 
============================
Mike Elliott    mre at m79.net
============================