Static effects of <type>.default

[John Rose]

You are appealing to the rules for unreachable statements
(JLS 14.21) which in turn depend on the specific definition
of constant expressions (JLS 15.28).

The net of it is, you are asking whether `int.default` should
be included in the definition of constant expression.

Pro:  It’s obvious exactly what the value is, at least for primitives
and non-inline reference types.  For inline types it’s not so obvious,
but maybe the rules could expand to encompass those as well.
Switch cases could have a pleasing form of `case int.default:`,
`case String.default:`, etc. when that makes sense.

Con:  Currently constant expressions are restricted to the
primitive types and String only.  Not even `null` is a constant
expression, so `null == null` and `"foo" == null` are not
constants either.  Making another form of `null` such as
`String.default` would therefore be inconsistent.

Making `int.default` an alias C.E. for `0` would be possible,
but it would create surprising inconsistencies of the form
`T.default` is not constant except maybe when `T` is `int`.

Allowing `V.default` to be a constant would entail building
out the story of what constant-preserving operations there are
on `V`.  As you note, `V.default == null` is not a very interesting
operation.  I do not expect that any method call on `V` would
qualify as a C.E., not even the implicit `toString` call entailed
by `V.default + " is my value"`.  It’s clearly not worth the effort
of expanding the story for inlines.

On balance, it is better not to disturb the rules of JLS 15.28.

BTW, I expect to keep the restriction to primitives and String
for a long time, perhaps relaxing it after we know more
about unifying primitives and inlines (e.g., “inline class int”)
and also the mechanics of compile-time evaluation (such as
javac intrinsics).  Neither of those topics is ripe for discussion
yet.

Conceivably the `T.default` syntax could be declared a form
of pattern, *in addition to* C.E.s, like `null`.  But the utility
is small there also, so I don’t recommend it.

— John