Reference-default style

[Elias Vasylenko]

I realise this has been said before, but it does seem particularly pertinent to this discussion so I hope it's not a bad time for a gentle reminder.

There is an assumption baked into all these approaches that there is only reliably one "good name" for any given class, but arguably that's not the case. It could be convention that the inline version of a type takes the same name but with a lowercase spelling, e.g. the inline version of `Optional` is `optional`.

With this convention, pretty much all inlineable types can reliably have a good name to refer to both inline and reference variants. As an added bonus, users can easily distinguish between them at the use site at a glance (assuming adherence to the convention can be relied upon).

This naming convention also happens to be convenient for migrating existing classes such as `Optional` and `DateTime`; we just introduce inline versions called `optional` and `dateTime` (or `datetime`?). This also works out neatly for primitives and their wrappers.

This doesn't obviate the need for the `.inline` and `.reference` type operators for two reasons. One, it would be icky to mechanically derive the alternate spelling, and we might not always want to force users to write both names down. Two, for type parameters. (For that matter why no `T.erased` operator? But that's not relevant.)

So perhaps there are a couple of other options.

6a) A single inline class declaration introduces two types, either one or both of which can be named. If only one name is provided it goes to the inline type.

    // create an inline class `point` with an unnamed reference projection
    public inline class point { /*...*/ }

    // create an inline class `optional` with a reference projection `Optional`
    public inline class optional<T> reference Optional { /*...*/ }

6b) As above, except if only one name is provided it goes to the reference type.

    // create an unnamed inline class with a reference projection `Node`
    public inline class Node { /*...*/ }

    // create an inline class `optional` with a reference projection `Optional`
    public inline optional class Optional<T> { /*...*/ }

The bikeshedding on how they'd be declared is just for the purposes of illustration and not a serious suggestion. The point is, I think if the barrier for declaring *two* "good names" is low enough then worrying about "inline default" vs "reference default" becomes redundant.

> On 20 December 2019 at 00:10 Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 19/12/2019 21:15, Dan Smith wrote:> Like many design patterns, (1) suffers from boilerplate overhead ((2) too, without some language help). It also risks some missed opportunities for optimization or language convenience, because the relationship between the inline and reference type is incidental. (I'd like to get a clearer picture of whether this really matters or not.)At the last post JVMLS meeting I was a string advocate of this position.This is effectively the pattern used in the Panama memory access API,where we have public (in future sealed) interfaces backed up byinline-ready implementation classes.
> While I still think that there will be a lot of cases like these -Panama also needs something which is more akin to the 'programmableprimitive'-half of the Valhalla glass. That is, we might want tointroduce a int128 type or float16, which might be required to interopwith certain system ABIs.
> When you do that, you would like to have these types (e.g. int128) the*public* ones, the ones with the good names. You want users to create(flat) arrays of them, rather than oops arrays.
> So, as much as I like (1) I don't think we can fully get away with that?
> Maurizio