Re: Discriminants of tagged types

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> The latest GNAT says:
>>
>> � � �1. with Ada.Finalization; use Ada.Finalization;
>> � � �2. package Eg is
>> � � �3. � �type T (X: Boolean := False) is private;
>> � � �4. private
>> � � �5. � �type T (X: Boolean := False) is new Controlled with null
>> � � �record;
>> � � � � � � � � � � � � � � � � �|
>> � � � � >>> discriminants of tagged type cannot have defaults
>>
>> � � �6. end Eg;
>
> My compiler eats this stuff without even blinking. It complains only
> when I add the "tagged" keyword in line 3, between "is" and "private".

OK, well then it's a compiler bug that has since been fixed.
Now that I think about it, I think I remember a recent bug
in this area.

I'll bet if you tried hard enough, you'd find some cases
where the compiler generated code that did strange things
(before the bug was fixed, I mean).

> Protected objects, tasks and records already supported it.

Records never supported this notation for calls,
which I thought was what we're talking about.

I wasn't a big fan of it for tasks or protected objects, either.
But at least for these things, a "distinguished receiver" does
make sense, because there's only one object getting locked.
And because inside the operation, you can only see inside that
one object.  That is, in X.Y(Z), X is special in the
protected object case, but X and Z are just normal parameters
in the normal tagged case.

>... It is not a
> new idea, so it wasn't that big deal for compiler writers, I guess.

Well, it was.  Maybe it wouldn't have been if this new syntax
had been invented in the first place, but adding this sort
of thing into an existing compiler can be quite a pain.

> I treat it as a unification of syntax across these similar features -
> quite a valid goal in language design.
>
> This is especially reasonable if you take into account that in Ada
> 2005 protected types can derive from interfaces. It would be very
> inconsistent not to allow the same calling syntax across the whole
> hierarchy, including the class-wide type.

Good point.  But I'd prefer to unify the syntax in the
other direction.

- Bob