Re: Controlled types and exception safety

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey R. Carter" <spam@spam.com> wrote in message
news:6z9mf.1704$Tg2.1265@newsread1.news.pas.earthlink.net...
> Randy Brukardt wrote:
> >
> > You're expecting a bitwise copy to work for that? That seems wrong;
since
> > the advantage to your scheme is that you can do operations on the old
> > left-hand side before the assignment. But if that "old" object is a
> > temporary, you have no access to it, and you have degraded to the
current
> > scheme. Except that it is worse, because you can't have
position-dependent
> > items.
>
> I'm not being very clear or precise, am I? We're talking about default
> assignment for a type with a component with user-defined assignment, but
the
> component doesn't exist in the LHS. If that's the only component with
> user-defined assignment, then you can't use the LHS during assignment
anyway, so
> you can assign to an intermediate for the whole value without losing
anything.
>
> If you have components with user-defined assignment in the LHS, and they
> continue to exist after the discriminants change, then you would use the
> components themselves. If you have a mix, then you can use intermediates
only
> for the objects that don't already exist in the LHS.

OK, that works, but it's useless (which is what I'm trying to point out). If
Assign might be called with a real LHS, or a fake LHS, then there isn't much
that you can practically do with the LHS in the Assign routine.

And, in any case, your model assumes component-by-component assignment,
while the Ada model is full object assignment. (That is, the discriminants
and components all change together.) What happens if the assignment fails?
It's important that the components that are disappearing are finalized.

Finally, the code you are suggesting would be very nasty; the assignment
would operate differently depending on the discriminant values of the LHS,
and the tests needed could be very complex.

> We've probably beaten this dead horse too much already.

Probably true. I guess my point is that this can't really be done, because
any way to make it work would be so complex so as to be impossible to get
right or understand. And such complexity usually leads to making it too hard
to use for the user of it as well.

> > That seems odd to me; what's the value of preventing aggregates of types
> > containing components of the limited type? (Preventing aggregates of
limited
> > private types is a feature of private types, not limited types.)
> >
> > Not in Ada 95; you can't write a useful function without standing on
your
> > head. Such a function can only return a global variable, which is ugly
at
> > best and impossible for anything but literal constants.
>
> I think we're talking at cross purposes. I'm talking about changes that I
> thought Ada 83 needed. You're talking about how things work in Ada 95. In
Ada
> 83, the only limited types were tasks and private types (and types with
limited
> components), and for the most part I'm thinking of limited private types
that
> are not limited in the full view.

Gee, I've done my best to forget that Ada 83 existed. We're on the second
(or third, depending on how you count) major update since then.

Limited private types that aren't limited in the full view are, for most
purposes, the same as non-limited types. Indeed, they're arguably a mistake
in the language (types that change limitedness are a continuing headache
with the semantics of Ada). What's interesting is the types that are
position-dependent, or are "really limited" -- these should never be copied,
even inside of their full definition.

In any case, being able to write with the natural syntax of ":=" is why
people want user-defined assignment, and it's the same reason that people
want initialization to work for limited types. (Unfortunately, ":=" is
overloaded in Ada, and initialization and assignment are completely
different. Ada 83 screwed up when it treated them as the same for limited
types, and we're finally fixing that now.)

                                 Randy.

                                Randy.