(j3.2006) Comment concerning TEAM_TYPE

[Malcolm Cohen]

Now, yesterday I wrote
> If everything in TEAM_TYPE is default-initialised, one does not need
> the constructor at all.

Which is where Van started to object saying that no, the constructor was 
necessary.

But as we see,

   "An object has default initialization if it is of a type that has default 
initialization."

and therefore the constructor is unnecessary in the context we are talking 
about.

>I don't see

Right.

>I don't understand the objection to simply saying

I might or might not object to "simply saying" one thing or another, what I do 
object to is making decisions on false premises.  The idea that the constructor 
is *NECESSARY* is false.

Whether we want to be dynamically creating "null or undefined team objects that 
are not variables", or whether we want to permit named constants that are "null 
or undefined team objects" is a separate discussion.  And actually maybe 
team_type is hunky dory but event_type has problems if we allow that.  The 
question is here is how hard the facilities are going to be nailed down, and 
there are many considerations in that, e.g.
(a) language elegance (!)
(b) implementation overhead
(c) efficiency
(d) robustness in the face of errors
(e) resistance in making errors in the first place.

All of these are important, but in my view in parallel programming (d) and (e) 
are very important indeed, and that is why I am focussing on the limitations. 
The more we limit how these things are used, the greater the likelihood that 
they will be used correctly.

Van has already made his case that it is convenient to be able to embed 
TEAM_TYPE in larger types, and convenient to be able to fully initialise the 
larger type object.  At the moment (N1983) the latter is not permitted. 
Permitting it would seem to require either that we allow constructors for 
TEAM_TYPE, allow named constants of type TEAM_TYPE, or that we permit the value 
for a nonancestor component to be omitted if all of its subcomponents are 
default-initialised.  Now *if* we want to permit full initialisation of a type 
containing a TEAM_TYPE subobject, and *if* we are all ok with dynamically 
creating non-variable values of type TEAM_TYPE then allowing the constructor is 
certainly the simplest of those ideas, but it is not the only course open to us.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.