[DRAFT] Composing by-constructor and non-by constructor types

[QuentinOchem]

No description provided.

[denismazzucato]

Minor comments below.

One thing that needs to be assessed, is that once a by-constructor type is component of a type T, then T becomes "implicitly" a by-constructor type. This is essential because then an implicitly by-constructor type might be used as component of other types, and in turn influence their kind of initialization. Also I think the same rules should apply to parent types, not only to components, no?

As a side note, I think we need to clear the implicit/explicit constructors. There are several differences that I didn't get when first reading the rfc, for instance that default initialization is permitted if a type only have implicit constructors, thus that type is not per se "by-constructor" but still we might be able to build it with both 'Make parameterless and default initialization. Or again that a regular type could be an implicit by-constructor, and as a consequence to forbid default initialization. I just wanted to point out that this difference isn't clear in the rfc but I'm not asking for any edit about it now.

[denismazzucato]

maybe better using rst lists? using 1. , 2. , and so on. Note that you will need to add a space to maintain the correct indentation then.

[QuentinOchem]

Sounds good.

[denismazzucato]

The rfc starts with "Constructors are available to both tagged and untagged records." I think the fact that we do not handle untagged types is unclear.

We should remove all references to untagged records, and specify that untagged records are not part of this proposal closer to the beginning.

[QuentinOchem]

Indeed - this is a leftover from an initial version of the proposal. Untagged record needs to be handled separately. I'll clean.

[denismazzucato]

Missing a dot.

[QuentinOchem]

Will fix.

[denismazzucato]

What is the exact definition of a "by-constructor type"? a type declared via a tagged record that has explicitly declared a constructor?

[QuentinOchem]

Yes - or that is derived from a by-constructor type. I'll make that explicit.

[denismazzucato]

A few more comments I've been thinking about (I can't comment on lines that are not modified by this PR but I think these are relevant):

• this section should be before the section about copy constructor and should define what is a by-constructor type so that it is clear when used afterwards
• above it's written that: "if not specified, a default copy constructor is automatically generated" I'd rephrase it to "for by-constructor types, if not specified, an implicit copy constructor is automatically generated". Otherwise, any type will have a copy constructor and thus will be by-constructor and will create problems later when another type extends or derives from it

[QuentinOchem]

Minor comments below.

One thing that needs to be assessed, is that once a by-constructor type is component of a type T, then T becomes "implicitly" a by-constructor type. This is essential because then an implicitly by-constructor type might be used as component of other types, and in turn influence their kind of initialization. Also I think the same rules should apply to parent types, not only to components, no?

There's indeed an issue of composition here. So we could take two stances - we can indeed implicitly propagate the "by constructor" aspect of types. This has impact on what you can do with types in particular with regards to default initialization - you should not be able to have a controlled be by constructor. The alternative is to only propagate whether or not a type has default initialization. E.g. in :

type X is tagged record
   null;
end record;

procedure X'Constructor (Self : in out X; V : Integer);

type C is record
   F: X;
end record;
--  C is not by constructor, but doesn't have default initialization

type C2 is record
   F2 : C;
end record
--  C2 is not by constructor, but doesn't have default initialization either

I believe that as far as limited goes (ie types without copy constructors), this propagation is already there.

As a side note, I think we need to clear the implicit/explicit constructors. There are several differences that I didn't get when first reading the rfc, for instance that default initialization is permitted if a type only have implicit constructors, thus that type is not per se "by-constructor" but still we might be able to build it with both 'Make parameterless and default initialization. Or again that a regular type could be an implicit by-constructor, and as a consequence to forbid default initialization. I just wanted to point out that this difference isn't clear in the rfc but I'm not asking for any edit about it now.

Ok - requires clarification indeed - I'll work on that. There's a difference between tagged and class types here:

• only tagged types that have constructors are by constructors. So if there's no constructor specified (and you don't derive from a type already by constructor), you're not a by-constructor type and there's no implicit constructor. I would argue that these types can't be build by 'Make (this is more for clarity than a real technical requirement).
• all class record types are by constructor whether or not they have an explicit one.

Does that make sense?

[QuentinOchem]

A few more comments I've been thinking about (I can't comment on lines that are not modified by this PR but I think these are relevant):

• this section should be before the section about copy constructor and should define what is a by-constructor type so that it is clear when used afterwards
• above it's written that: "if not specified, a default copy constructor is automatically generated" I'd rephrase it to "for by-constructor types, if not specified, an implicit copy constructor is automatically generated". Otherwise, any type will have a copy constructor and thus will be by-constructor and will create problems later when another type extends or derives from it

Agreed - will fix.