(update) Use "default" keyword for default visibility

[Adrian Kuhn]

Updated the default visibility proposal

PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

AUTHOR(S): Adrian Kuhn

OVERVIEW:
Allow the "package" keyword to be used as modifier for default  
visibility.

FEATURE SUMMARY:
Use "package" keyword for default visibility.

MAJOR ADVANTAGE:
This change is a "5 cent coin" at best, there are not many advantages  
beyond improved readability and a more beautiful language definition.  
However, the benefit of improved readability is not to be  
underestimated. The missing keyword for default visibility breaks the   
symmetry of visibility modifiers. The use of package visibility is  
less obvious than other visibility since an explicit modifier is  
missing. This decreases readability of source code. For example,  
omitting any of the three explicit modifiers by mistake (or vice verse  
mistakingly adding any of the tree) may introduce unexpected behavior  
which is hard to spot due to the bad readability.

MAJOR BENEFIT:
Improved readability.

MAJOR DISADVANTAGE:
Two ways to express the same thing (in compatibility mode).

ALTERNATIVES:
- Using /*default*/ comments (as often seen) is not an alternative  
since such comments are not processed by the compiler.
- Using a custom-made @Package annotation is feasible (it is what I  
use now) and can be processed by the compiler using an annotation  
processor.

EXAMPLES

SIMPLE EXAMPLE:
public class Point {
	package int x;
	package int y;
}

ADVANCED EXAMPLE:
package ch.akuhn.util;
package class Foo {
}

DETAILS

SPECIFICATION:
"package" is already a keyword, introducing it as a new visibility  
modifier is thus save. To distinguish package visible top-level  
classes and package declarations, the grammar will need a lookahead of  
two tokens (I dont know if this is a problem).

COMPILATION:
Same as now with implicit default visibility.

TESTING:
Same as now with implicit default visibility.

LIBRARY SUPPORT:
None.

REFLECTIVE APIS:
None.

OTHER CHANGES:
None.

MIGRATION:
See below, strict vs compatibility mode.

COMPATIBILITY:
A compiler switch is offered to set either strict or compatibility  
mode. In strict mode, an error is issued if a member has not  
visibility modifier. In compatibility mode, members without visibility  
modifier as treated as default visibile (which is the current  
semantics of Java).

BREAKING CHANGES:
None.

EXISTING PROGRAMS:
Work fine in compatibility mode.

REFERENCES

EXISTING BUGS: To my best knowledge, none.

URL FOR PROTOTYPE (optional):

On Mar 3, 2009, at 13:01 , Stephen Colebourne wrote:

>> PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>> AUTHOR(S): Adrian Kuhn
>> OVERVIEW
>> Allow the "default" keyword to be used as modifier for default   
>> visibility. In strict mode, missing use of default is a warning /   
>> error, in compatibility mode both the current (ie no default  
>> keyword)  and the new syntax are accepted.
>> FEATURE SUMMARY: Use "default" keyword for default visibility.
>> MAJOR ADVANTAGE: The missing keyword for default visibility breaks  
>> the  symmetry of visibility modifiers. Since it is the only  
>> implicit  modifier, omitting any of the three explicit modifiers by  
>> mistake may  be the source of unexpected behavior and thus hard to  
>> track down bugs.  (There was an example on a blog post recently,  
>> but I cannot find it  know).
>> MAJOR BENEFIT: Symmetry of visibility modifiers is restored.
>> MAJOR DISADVANTAGE: Two ways to express the same thing (in   
>> compatibility mode).
>> ALTERNATIVES: Using a comment such as /* default */ is not an   
>> alternative since such comments are not processed by the compiler.
>> EXAMPLES
>> public class C {
>> 	default Field f;
>> }
>> SIMPLE EXAMPLE: See above.
>> ADVANCED EXAMPLE: None.
>> DETAILS
>> SPECIFICATION: "default" is already a keyword and introducing it as  
>> a  new visibility modifier is save, it does not lead to ambiguous  
>> grammar.
>> COMPILATION: Same as now for implicit default visibility.
>> TESTING: Same as now for implicit default visibility.
>> LIBRARY SUPPORT: None.
>> REFLECTIVE APIS: None.
>> OTHER CHANGES: None.
>> MIGRATION: Compatibility mode allows both, implicit and explicit   
>> default visibility, to be used at  the same time.
>> COMPATIBILITY
>> BREAKING CHANGES: None.
>> EXISTING PROGRAMS: Work fine in compatibility mode.
>> REFERENCES
>> EXISTING BUGS: To my best knowledge, none.
>> URL FOR PROTOTYPE (optional):