Re: Generic access type convention and aliasing

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 07 May 2013 02:56:34 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> We eventually realized that access discriminants already had the correct  
> semantics so we didn't need a new feature for that.

I don't see how:


     package Storages is

        type Element_Type …; -- With the real case, a generic parameter.

        type Element_Access is access Element_Type;

        type Instance_Type
          (Element : Element_Access := null) is
           limited
           private;

        function Create
           return Instance_Type;

     private

        type Instance_Type
          (Element : Element_Access := null) is
           null record; -- With the real case, management data.

        function Create
           return Instance_Type
           is (Instance_Type'(Element => null));

     end Storages;

     S1 : Storages.Instance_Type  := Storages.Create;
     S2 : Storages.Instance_Type  := S1; -- Illegal.
     A  : Storages.Element_Access := S1.Element; -- However still legal.


That makes the `Element` member constant (one of the thing I wanted); that  
does not prevent from copying it. Implicit deference, even if it avoids  
direct use of the access member (syntactic sugar, not added safety,  
although a good idea), does not prevent copying it neither, as it requires  
to expose the access discriminant in the public part. I know no way to  
prevent copying this member, except wrapping every use of the access  
member in many functions and procedures or using reader/updater callbacks,  
which is something I prefer to avoid; that's why I was looking at this AI  
about limited access types (didn't care enough for its status, sorry, I  
note this is indeed “No action”).

By the way as a side note, even if using a boolean discriminant for the  
storage allocation status is expressive, using null for the access and  
that access as a discriminant, is more resilient, as an error with it when  
null, will be more surely caught at runtime whenever compiled without  
validity checking, where a not‑really existing member, thus returning  
probably not‑null garbage, may have enough time to break something before  
being caught.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University