Why change default values?

[bwilkerson]

With respect to the interface view, the proposal states:

Any default arguments for these functions are replaced with null.

and

const fields and constructors are maintained as-is, since they're guaranteed to be available across platforms and new behavior can't be added without breaking the existing API.

Given that default values must be compile-time constants and other compile-time constants are assumed to be ok, why change the default values of optional parameters?

[nex3]

My thinking was to remove them because they don't do anything and they're just extra unnecessary tokens—basically, removing as much as possible rather than keeping as much as possible. Is there a use-case for keeping them around that I'm not thinking of?

[bwilkerson]

Section 10.1 states:

It is a static warning if an instance method m1 overrides an instance member m2 and the type of m1 is not a subtype of the type of m2. It is a static warning if an instance method m1 overrides an instance member m2, the signature of m2 explicitly specifies a default value for a formal parameter p and the signature of m1 implies a different default value for p.

It probably wouldn't matter, because at analysis time we'd normally be comparing against the normal view of the libraries, but if we ever wanted to analyze against the interface view then nulling out default values could cause warnings in overriding methods that shouldn't be there.

[nex3]

Okay, I didn't realize they were technically part of the signature. I'll update the proposal as soon as I can (but it may be once I get back from vacation).