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

[Brian Goetz]

> It's how I interpret our requirements, I guess?
> 
> The vision of B3 is "user-defined primitives": that someone can define in a library a type that can be used interchangeably with the existing built-in primitive types. (We can debate whether "primitive" is the right word here, but the concept persists under whatever naming scheme.)
> 
> If the expectation is that a typical programmer is going to look over their menu of types and choose between 'int', 'long', or 'Integer128.val', I think we've heavily biased them against the third one. The syntactic overhead is just too much.

s/is/may be/

I’ve gone back and forth on this a few times as our understanding of the reality gets refined, and surely there’s room for multiple opinions.  

There are clearly useful choices to be had at both the declaration and use site.  If a class has no sensible default, then it’s a B2, and there’s nothing more to be done; if it does, then *maybe* it can be a B3.  So this choice — about zero defaults — has to be made by the class author.  

If the class author says that zero is a sensible default, the client has choices at the use site, such as nullity.  Do they want to represent only dates, or the possibility of no date being present?  While clearly the latter choice depends on the former (you can’t choose .val for a B2), we want to empower both users — the class writer and the class user — to make these choices for themselves.  

> Whereas if we're saying "just use plain reference type 'Integer128', it'll usually be fine", that's probably something we can sell (if we can deliver on "usually fine"), even though the menu will be more like 'Integer', 'Long', and 'Integer128’.

Fine is relative.  For mainstream users, the .ref type probably is fine most of the time; its better than B1 would be, and B1 is often fine now.  Where the real money is is when we have big arrays of flattenable types, because both the footprint and any accidental indirections / atomicity costs are multiplied.  

I guess I’d like to defer judgment on this bit of low-level syntax issues for a bit, while we let Kevin’s points sink in, and more importantly, figure out the role of the various opt ins (id-free, null-free, tear-free) into the story.