Christoph Grein writes:
> First of all: Merry Christmas to all of you and Happy New Year
Are you sure you sent this the right time of year? It seems more like an
April Fool's note to me. But Merry Christmas to you as well, just don't
expect a lengthy and detailed answer for a while.
> Which record components of One_Horse_Carriage do exist? Code see at
end.
First, was this something that was encountered in actual use, or is it more
of a language lawyer thought experiment. It's pretty clear that changing
discriminants on untagged derived types is one of those features that keep
language lawyers employed; they tend to break many otherwise good ideas.
Moreover, they seem to be largely useless. Indeed, until Ada 2022 one
couldn't even have a different representation for a derived type, so any
untagged derivation was close to useless (the main usage has been to rename
a type into a different scope, and they're not ideal for that). Changing
discriminants are not necessary for that primary use, so actual usage is
next to none. I'd guess that totally removing the feature from Ada would
affect essentially no one except those that run the ACATS. (I don't recall
ever having a bug report on this feature in Janus/Ada, even though it is
known not to work in a number of corner cases.)
As to whether the discriminants exist, on what basis:
(1) Logically in the user view: They don't exist, thus they don't appear
in aggregates.
(2) To an implementation: Of course all of the discriminants exist
(certainly in the absence of a representation clause). The record
representation has to be the same for many derived record types (for
instance, consider if the parent type was a by-reference type), otherwise
conversions would be impossible. And certainly they exist for any fully
constrained subtype, so it would be bizarre to try to do without them only
in the weird case of a partially constrained derived type. It's too much
work to implement such a type in the absence of anyone caring beyond passing
ACATS tests.
>... [Image attribute] ... Does this make sense if the parent type has more
components than the derived type?
Well, most of the time, yes. If the parent type has a user-defined
Put_Image, we certainly want to use it. And assuming the derived type has
the same representation (it certainly will in this example), it makes sense
to use the same Image. I don't think we ever promised that the Image was
something that could be used directly as an aggregate.
---
I'm not going to spend any more time on this now. Christmas, you know. ;-)
I'm not entirely sure what question you are actually trying to ask. I'd
argue that the only important thing about this feature is that it is defined
in each case such that there is no language hole. Beyond that, no one uses
this so no one will ever care how it is defined.
I don't think it is possible to consistently define this feature (since it
depends on the rather nasty idea of hiding components that still exist), and
I don't know if it is worth anyone's time to try.
How do YOU want this to work?? Explain your answer.
Randy.
________________________________________________________
You have received this message because you subscribed to the Ada-Comment
mailing list. To leave the Ada-Comment list, send an email with
'leave Ada-Comment' in the body to [email protected]. For help
on the other commands available, send 'help Ada-Comment' to the same address.
Problems? Send mail to [email protected]. This list is operated by the
Ada Resource Association, Inc., PO Box 8685, New York NY 10116-8685.
