Explicit name for value companion type

[John Rose]

On 1 Jul 2022, at 5:39, Brian Goetz wrote:

> Now that the model is settling, the messages in the suggestion box --
> many of them syntax-driven --
> are coming fast and furious now.  Here's another.
>
>  Summary: "Having to type .val will make users angry; can we please 
> find a way to make it the default at least sometimes."

Having to guess the name of the value companion type will make
a different set of users angry (including me). Also the
spec-writers and teachers will lose a useful tool.

My take:  Start with a standard (dumb but effective) name
like `C.val` for “the value companion for class `C`”.  Live
with its boring but useful predictability for a while.
Later, add some sort of separable “type alias” mechanism
that polishes not just this one flyspeck but cleans up a
whole raft of naming issues.  There are no shortages of
examples Java might follow in this area.

Another take:  There is a basic difference between use-site
and def-site declarations, and type aliases can (and should?)
go on both sides.  But it is natural and easy to put them
on the use-site first, perhaps an “import … as …” thing.
Then maybe something that feels like a type-member, but is
also an alias.  Remember that type-members are easy to
import, if you want to use their unqualified names.

Yet one more take:  Compiling alternative type names into
class file linkage is a losing proposition.  Let’s not.
This is another reason to embrace  `C.val` and the JVM’s
Q-descriptors, instead of some complicated landscape of
mapping tables that will be endlessly out of date.
Type aliases need to be canonicalized at javac-time.

Final thought:  Notice that we don’t really need to do
anything about this immediately; the type alias idea
will keep.  Let’s table it; we have enough to worry about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220702/e6dde493/attachment.htm>