[External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Brian Goetz]

What I’m thinking here about migration is that existing APIs can say “Optional” but field declarations can say Optional.val, getting additional footprint / flattening benefits, without perturbing the APIs (and with cheap conversions.)

Aren't most of the migration cases (at least for existing VBC)
targeting B2?  They need to keep the reference semantics due to
existing code using null and will still get optimized inside a
compiled body.

Sort of.  For existing uses, we’re stuck with compatibility with the L protocol, certainly.  But consider this example:

    class Foo {
        private Optional<Foo> f;

        public Optional<Foo> f() { return f; }
    }

The API point has to stay LOptional, but the field could migrate further to QOptional, and there’s definitely value in that.  With the current stake in the ground, we have no way to get there, but with Kevin’s proposal, we have the option to go further.

I'm a little concerned we're starting to undo the
separation between B2 & B3 (just add .val to any B2 class) and will
drag ourselves back into the quagmire.  B2 and B3 are different points
on the spectrum and we should respect the user's intention when they
pick one of those points.

But they’re coupled; a B3.ref is a B2.

Yes, that’s the risk.   (Still, primitives today LOOK DIFFERENT from class names.)

So we should guide primitive B3 classes to use lower case names?
"complex" rather than "Complex"?  This started tongue in cheek but
it's kind of growing on me as a convention.  It matches the existing
primitives, makes it clear at glance (no need to carry a type
dictionary in your head), and works fine with the ".ref" escape hatch.

Give it time, you’ll cycle back :)