The idea of implicit vs default

[John Rose]

On 20 Jan 2024, at 15:24, Jonathan F wrote:

>> The way I like to see it is the implicit constructor is a real constructor, but it is prevented from doing any field assignments, guaranteeing those favorable zero-rich fields.  Giving a name to the result of that constructor>
>> is possible (as you point out) but it doesn’t seem to buy much. The VM could notionally assign a named value when necessary and/or it could notionally call a no-op constructor when necessary:  Is there much of a difference, at the level of user model?

>
> Yes there is! …at least the way I understand it, as follows:
>
> Current story: when a field/array element is created, the type's default
> value (normally null or 0) is stored in it. But for Point!, this value has
> to be created by (notionally) calling its constructor, which seems so
> different this process has been given the name ‘implicit’.
> New story: when a field/array element is created, the type's default value
> is stored in it. That’s it.

But then we define the default value as the thing you get when you
run the mandated empty constructor, and I think the two notions
collapse together.  We don’t (yet) have a notion of “default value”
in the language (other than zero), so there’s no place to “hang”
the result of calling the empty constructor.  If the empty
constructor could produce side effects or varying values at
varying times there would be a logical distinction between
the result of calling it yet another time and calling it once
and saving the result.  But (by design) there is no possible
variation or side effect.

> And ideally, maybe this value could be
> uniformly called T.default.

At that point it’s not the default for a value class; you’d want to say
T!.default to get the thing we are talking about.

> You’ve got a fair point that _if_ Point.default were introduced just for
> this purpose then little is gained, but I thought Point.default was likely
> to happen anyway? And (speculating wildly) there may be a long-term plan to
> have T.default generally for any type (it feels important for generic
> code), but I know how cautious the EG has to be with all this.

At present T.default feels unlikely to me, even as a tool for generic
programming.  IF we allow class witnesses in specialized generics,
THEN the foundational syntax would probably be T.class (where T is
a type variable equipped with a class witness).  And then T.default
looks like very weak sugar. You can get it from a suitable API, such
as T.class.defaultValue().  If we don’t allow class witnesses, we
still need some other witness-like mechanism that “anchors” each
specialization.  (Have you seen my Parametric VM sketch?)  And
again an API point does what T.default would do.