Use "default" keyword for default visibility.

[Adrian Kuhn]

On 01.03.2009, at 10:15, Jeremy Manson wrote:

> Could you dig up the example?  It is hard to see why this is
> compelling without it.

I am working on it ... to many inboxes :)

> I think it would have to be a warning instead of an error, because
> otherwise, it is a change that breaks backwards compatibility (i.e.,
> it makes old stuff not compile).  I think there is a reasonable sized
> danger in introducing so many warnings for a change this small; people
> are likely to ignore / get upset about the flood of warnings that
> their compiler is suddenly generating.
>
> Did you consider the use of annotations as an alternative?  In code
> that I write, if something has package-private visibility, it is
> usually for testing; Google has a @VisibleForTesting annotation that
> we use.

I do, and actually use an annotation processor to reject non-annotated  
default visibilities. It works but feels ugly, since (at least  
optically) symmetry of visibility modifiers is still not given.

> Also, why not use the package keyword?

Wow, that's much better!

However because both package and class declaration can start with  
package now, we might need a lookahead of two tokens in the grammar.

--AA

> Jeremy
>
> On Sun, Mar 1, 2009 at 1:01 AM, Adrian Kuhn <akuhn at iam.unibe.ch>  
> 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):
>>
>>
>>
>>