Version 1.1 of ai05s/ai05-0026-1.txt

From: Pascal Leroy
Date: Monday, October 23, 2006  9:15 AM

Three questions on pragma Unchecked_Union.

1 - B.3.3(10/2) says that "A component declared in a variant_part of an
unchecked union type shall not have a controlled, protected, or task
part".  This rule is wildly privacy-violating.  Why don't we just assume
the worst for private types (and private extensions)?  Of course, for
generics we would need the usual rigmarole of assuming-the-worst in the
body and rechecking in the specification.

2 - The !proposal of AI95-00216 explains that "it is illegal to mention a
discriminant explicitly in a component clause", which seems like a good
idea.  However I can't find a rule that would have that effect.  I can't
find anything in the minutes that would indicate that we changed our mind.
So is it just that we forgot to put the rule in the wording?

3 - B.3.3(9/2) says that "Any name that denotes a discriminant of an
object of an unchecked union type shall occur within the declarative
region of the type".  I am not too sure what "a discriminant of an object"
means.  Consider an aggregate in named notation like (D => 2, C => 3.14).
I would naively think that the name D denotes the discriminant of the
(anonymous) object for the aggregate.  In this case, the above-mentioned
rule would make the aggregate illegal, which would be obnoxious.

****************************************************************

From: Robert Dewar
Date: Monday, October 23, 2006  9:20 AM

> 1 - B.3.3(10/2) says that "A component declared in a variant_part of an
> unchecked union type shall not have a controlled, protected, or task
> part".  This rule is wildly privacy-violating.  Why don't we just assume
> the worst for private types (and private extensions)?  Of course, for
> generics we would need the usual rigmarole of assuming-the-worst in the
> body and rechecking in the specification.

So what? Unchecked_Union should be regarded only as a way of interfacing
to C, and C has none of this junk. Yes, I know a lot of junk has crept
in already that is not C related. I objected strongly to Tuck's over-
generalization here, but let's not make it even worse. The idea of
unchecked unions of tasks and controlled types is truly horrible :-)

****************************************************************

From: Tucker Taft
Date: Monday, October 23, 2006  10:01 AM

> 1 - B.3.3(10/2) says that "A component declared in a variant_part of an
> unchecked union type shall not have a controlled, protected, or task
> part".  This rule is wildly privacy-violating.  Why don't we just assume
> the worst for private types (and private extensions)?  Of course, for
> generics we would need the usual rigmarole of assuming-the-worst in the
> body and rechecking in the specification.

Unchecked union is similar to a representation clause,
so privacy breaking doesn't seem too bad.  In some ways
it would seem worse to disallow all private types from
unchecked unions.  I suppose we only need to disallow
private types whose full type is not visible immediately
within the scope where the unchecked-union type is defined.
That is probably adequate, since if you really need
an unchecked-union containing a private type, you can define
it in the same scope where the private type is defined.

> 2 - The !proposal of AI95-00216 explains that "it is illegal to mention a
> discriminant explicitly in a component clause", which seems like a good
> idea.  However I can't find a rule that would have that effect.  I can't
> find anything in the minutes that would indicate that we changed our mind.
> So is it just that we forgot to put the rule in the wording?

Seems plausible.  ;-)

> 3 - B.3.3(9/2) says that "Any name that denotes a discriminant of an
> object of an unchecked union type shall occur within the declarative
> region of the type".  I am not too sure what "a discriminant of an object"
> means.  Consider an aggregate in named notation like (D => 2, C => 3.14).
> I would naively think that the name D denotes the discriminant of the
> (anonymous) object for the aggregate.  In this case, the above-mentioned
> rule would make the aggregate illegal, which would be obnoxious.

That was certainly not the intent.  I would say that a use of a
selector_name in an aggregate does *not* denote the discriminant
of an *object*.  It denotes the declaration of the discriminant.
I believe that we should interpret "name that denotes a discriminant
of an object" as a name that is used in a context where it
is interpreted as the name of a value or an object, such as
in an expression context, or as the prefix of a larger name.

Or even simpler, if you look at the syntactic category "name"
it does *not* include "selector_name."  So the "D" in your
aggregate above is not a "name" at all, in the sense that it
is not of the syntactic category "name."  (This is reminiscent
of the fact that a "generic package" is not a "package" despite
lexicographic appearances to the contrary.)

****************************************************************

From: Pascal Leroy
Date: Tuesday, October 24, 2006  2:50 AM

> Unchecked union is similar to a representation clause,
> so privacy breaking doesn't seem too bad.

I hate privacy breaking, in part because it's hard to implement in our
technology.  But if we have to have a privacy breaking in this case, I
would argue that it should say "needs finalization" (which is already
privacy-breaking, being related to restrictions).  There is no point in
forcing compilers to compute a slightly different predicate for this
particular rule.

Not to mention that we would still need a specific assume-the-worst rule
for generic formal types.

> In some ways
> it would seem worse to disallow all private types from 
> unchecked unions.  I suppose we only need to disallow private 
> types whose full type is not visible immediately within the 
> scope where the unchecked-union type is defined. That is 
> probably adequate, since if you really need an 
> unchecked-union containing a private type, you can define it 
> in the same scope where the private type is defined.

Unfortunately that's not quite true.  There is an IA recommending that
System.Address be a private type (13.7(37)).  Having a C union containing
an address doesn't seem unreasonable.  But I don't think we want to force
users to declare such unions in children of System...

****************************************************************

From: Pascal Leroy
Date: Tuesday, October 24, 2006  2:55 AM

> The idea of unchecked unions of 
> tasks and controlled types is truly horrible :-)

It is, but now that we have this rule in the RM it should be well-defined,
and implementers should know what to do with private types.  Only the
mildly insane would want to put tasks in unchecked unions, but as I
mentioned in a previous message, there is at least one private type which
is of interest here, and that's System.Address.  I want to know if an
unchecked union with an address in it is legal or not (I realize that
Dewar's rule says "of course, how could anyone think otherwise").

****************************************************************

From: Robert Dewar
Date: Tuesday, October 24, 2006  6:26 AM

Indeed System.Address is probably the MOST useful type in an unchecked
union, so that must indeed work.

****************************************************************

From: Robert Dewar
Date: Tuesday, October 24, 2006  7:03 AM

> Unfortunately that's not quite true.  There is an IA recommending that
> System.Address be a private type (13.7(37)).  Having a C union containing
> an address doesn't seem unreasonable.  But I don't think we want to force
> users to declare such unions in children of System...

System.Address must be allowed in unchecked unions, and of course we 
can't require such unions to be in children of System (which may not 
even be allowed in some implementations.

So this must work by the Dewar rule, and if it is necessary to fix
the RM to allow this, it must be fixed, hopefully without dragging
more horrible irrelevant junk into unchecked union.

****************************************************************