(j3.2006) Comment concerning TEAM_TYPE

[Van Snyder]

On Wed, 2013-10-09 at 10:08 +0900, Malcolm Cohen wrote:
> (b) the ancestor component is default-initialised: read 4.5.4.6p8.

4.5.4.6p8 says

        A type has default initialization if <component-initialization>
        is specified for any direct component of the type. An object has
        default initialization if it is of a type that has default
        initialization.

I don't see how to get from there to the ancestor component being
default initialized, since <component-initialization> is not (indeed
cannot) be specified for the parent component, and in any case a
component (parent or otherwise) is not an object, at least not according
to 1.3.45.  If it's meant to say that the parent component is default
initialized, maybe the wording needs some work.

Indeed, I'm not sure whether 4.5.4.6p8 (or any other text) means that

  type :: T1
    integer :: A = 0
    integer :: B
  end type T1

  type :: T2
    type(t1) :: X
    integer :: Y = 42
  end type T2

  type(t2) :: V2 = t2()

is (or is not) legal.  Similarly, I cannot see how 4.5.4.6p8 (or any
other text) means that

  type, extends(t1) :: T3
    integer :: Z = 42
  end type

  type(t3) :: V3 = t3()

is (or is not) legal.  By the reasoning that Malcolm apparently
advocates but that I cannot follow, the X component of T2 has default
initialization because the type T1 has default initialization, and the
parent component of T3 has default initialization for the same reason.
Therefore one doesn't need a <component-spec> for X in the T2()
constructor, or for T1 in the T3() constructor.

I would prefer that a component not be default initialized unless it has
<component-initialization>, or ALL of its direct components (not just
one of them) have default initialization.

The TS says nothing whatsoever about default initialization for
components of team_type.  Therefore, even if 4.5.4.6p8 does somehow mean
that a parent component is default initialized if any of its direct
components are, it is irrelevant because a team_type parent component
wouldn't be default initialized, and the type extension kludge wouldn't
work.

I don't understand the objection to simply saying in the TS that
team_type has default initialization for all of its components, which
default initialization results in a team_type object whose value has
never been defined by a FORM TEAM statement.

That makes the constructor available, and obviates the need for the type
extension kludge (assuming it actually works) if one wants to create a
type having team_type components and initialize variables of that type.

Named constants of team_type would be possible unless explicitly
prohibited (why bother?), but useful only for initialization.

If a CHANGE TEAM statement were to be executed using a team variable for
which no value had been defined by a FORM TEAM statement, would it be
better for the behavior to be undefined because the team variable is
undefined, or to produce a status (or error message) indicating that no
value had been provided by a FORM TEAM statement?

The latter seems better to me, but wouldn't be reasonable unless values
of type team_type are specified to be default initialized to a value
that means the object has never had a value assigned by a FORM TEAM
statement.  The step from there to "all the components are default
initialized" doesn't seem to be profoundly difficult.