Keeping `new Integer` source compatibility with unnamed factory method

[John Rose]

On Nov 8, 2020, at 9:38 AM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> Unless... could specialization help -- int being a primitive species of
> Integer while having another reference species available for _mature_ code?
> I dimly remember both Fred and John, I think, making such remarks...

Yes, something like that might be possible.

We know we want to allow fields to change their
storage types in different species.

We also know we want to support some kind of
“raw species” for each class C, that emulates the
legacy characteristics of the class C, including
erased (invariant) field types.  From that POV,
the “raw type” for Integer should, clearly, be
a type that has object identity, while the factory
methods should return the new-and-cool
non-identity instances.

(Would we want to inject object identity for
the raw species of *any* inline/primitive class?
I can see pros and cons.  Mostly cons.  Identity
injection is a migration trick for legacy classes.)

Having an object type conditionally possess an
object identity is *a little* like having it have
a conditional field.  But I hope to model conditional
fields and methods using, not retractable declarations,
but rather type restrictions to an “empty type”, such
as “void”.  It’s not clear how to do that to an optional
object identity property.

In this case we would want something a little more
difficult:  A conditional *super*, of IdentityObject.
We don’t have any specific plans to do conditional
supers, but we might be able to create a compromise
that gets this job done.  I can think of two or three,
potentially.  I’d rather build the basics first, though,
and then return to this question.

So, maybe.

— John