Re: discriminant questions

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:148cxoyabima2.16mz6xwdph2hj.dlg@40tude.net...
> On Sat, 17 Sep 2011 15:55:15 -0700 (PDT), ytomino wrote:
...
>> This code is same as:
>>
>> type Reference_Type (Element : access Integer) is null record;
>
> It is not same, and I don't see the purpose of using this construct. In 
> any
> case it cannot serve as a good basis for smart pointers.

The "good reason" for using this construct (beyond the obvious one of being 
able to use the "implicit dereference" construct is one of lifetime. The 
access discriminant of this object has the same lifetime as the enclosing 
object; if that object is returned from a function, that is very short.

That's important to prevent users from creating dangling pointers to 
elements stored inside of a container (including a smart pointer container). 
What we want is for the container to be able to manage the actual objects as 
it sees fit, so it should not be possible for a user to keep an access to an 
element for any length of time.

We originally had looked at other ways of getting this safety, but 
eventually it was pointed out that we already had a way to get it with the 
existing constructs. Thus we simply used those constructs rather than 
creating more rules and cruft -- the only new things here are the aspects 
that allow dropping part of the text (the name of the discriminant).

We then went a step further and defined indexing operations that allow 
omitting even more of these calls, making them syntactically look like array 
indexing.

It should be noted that the primary purpose behind all of these things is 
making the Vector and Map containers easier to use; the others are made 
consistent but they were not the primary focus. I don't think they help much 
for the Holders (and we decided not to use them on the unbounded strings 
because writing would not have worked well).

                                          Randy.