Re: Extension of non-limited type needs limited component

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

Robert A Duff wrote in message ...
>"Randy Brukardt" <randy@rrsoftware.com> writes:
>> I don't recall why you are not allowed to make the extension of the
>> limited type non-limited. (I didn't find anything in the AARM on this
>> subject.)
>
>I don't think it would work, because ":=" on a derived type copies the
>parent part, which is limited, and therefore not copyable:
>...
>The assignment above is copying a task, which is bad news.  It is also
>copying an access discriminant, which is bad news.  Also, the component
>Self of X is supposed to point at X, and the assignment defeats that.


I knew there was a reason, I just couldn't figure out what it was. I'm
surprised that this discussion is not in the AARM, because it is such a
restrictive rule that you'd think that there would have been a
justification for it somewhere.

>I suppose it could work if all ancestor limited types are not private.
>Then we could add a rule saying that deriving a new non-limited type is
>OK if the ancestor types *could have been* non-limited -- that is, they
>don't violate any of the rules for non-limited types (e.g., no access
>discriminants allowed).
>
>But that would be a rather severe restriction -- I *want* most of my
>types to be private.


No, that's not going to work. And, of course, breaking privateness would
also be a bad idea (even though it would work in this case.

>Here's another alternative: you could invent a new kind of type --
>"pseudo-limited".  A pseudo-limited type disallows assignment
>statements, but *also* disallows all the things disallowed for
>non-limited types.  A pseudo-limited type can have pseudo-limited
>components, and non-limited components, but not limited components.
>Then you could have a hierarchy with the root of the tree
>pseudo-limited, with some subbranches being limited and some
non-limited
>(and some pseudo-limited).


That would work, I think.

>Sounds complicated.  I haven't thought it through, so I'm not at all
>sure it even works.


But I have to agree with the 'sounds complicated'. I doubt that this
problem is severe enough to justify a solution like this. (We've had
other problems with simpler solutions shot down, after all.)

            Randy.