From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3a7c118fd2cc64f9
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder.news-service.com!kanaga.switch.ch!news-zh.switch.ch!switch.ch!news.belwue.de!LF.net!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: A hole in Ada type safety
Date: Sun, 01 May 2011 12:26:49 +0200
Message-ID: <87d3k2u36e.fsf@mid.deneb.enyo.de>
References: <87oc3odtci.fsf@mid.deneb.enyo.de>
	<wccoc3oq7ev.fsf@shell01.TheWorld.com>
	<87tydfbtp3.fsf@mid.deneb.enyo.de> <ipi6kl$cbd$1@munin.nbi.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ruchba.enyo.de 1304245610 4316 172.17.135.6 (1 May 2011 10:26:50 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:pNiRcEf/vY+mVy5F8zOPniBMzZo=
Xref: g2news1.google.com comp.lang.ada:19109
Date: 2011-05-01T12:26:49+02:00
List-Id: <comp.lang.ada>

* Randy Brukardt:

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
> news:87tydfbtp3.fsf@mid.deneb.enyo.de...
> ...
>> And once there is something like this in the language, it is difficult
>> to decide if a new addition (such as aliased parameters) make things
>> worse or not.
>
> Not sure how something that adds new capabilities only for
> elementary types could make anything worse.

It introduces a new form of aliasing.  This will be problematic, I
fear.  In particular, extreme care is necessary so that the cop-out in
3.7.2(4) is still the only one which is needed.  With this rule (I
don't know if this is the current text):

| If the formal parameter is an explicitly aliased parameter, the type
| of the actual parameter shall be tagged or the actual parameter
| shall be an aliased view of an object.

it is possible to obtain an aliased view of a discriminant-dependent
record component of tagged type which is not delimited by a subprogram
call.

This would allow to write the Conversion function like this:

   function Conversion (S : Source) return Target is
      type Source_Wrapper is tagged record
         S : Source;
      end record;
      type Target_Wrapper is tagged record
         T : Target;
      end record;
      
      type Selector is (Source_Field, Target_Field);
      type Magic (Sel : Selector := Target_Field) is record
         case Sel is
   	 when Source_Field =>
   	    S : Source_Wrapper;
   	 when Target_Field =>
   	    T : Target_Wrapper;
         end case;
      end record;
      
      M : Magic;
      
      function Convert
        (T : aliased Target_Wrapper) 
        return access constant Target
      is
      begin
         return T.T'Access;
      end Convert;
      
      T : Target renames Convert (M.T).all;
      
   begin
      M := (Sel => Source_Field, S => (S => S));
      return T;
   end Conversion;

(I haven't checked with an Ada 2012 compiler, so this is somewhat
speculative.)

It seems to me that you need a C++-like rule that accessing an object
through a view which is not compatible with its dynamic type is
erroneous.  And this would be quite a defeat.

The difficulty I alluded lies in the answer to this question: Are
aliased parameters at fault, or are discriminants with defaults to
blame?

> Cases like this is why I like to say that all real Ada programs are 
> erroneous, so any result is allowed. :-)

It's a bit disappointing because all those nitty-gritty rules intended
to ensure type safety which make the language quite complicated, and
there's still such a hole.  It's certainly at odds with the marketing
materials.