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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.szaf.org!news.enyo.de!.POSTED!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Intervention needed?
Date: Fri, 29 Mar 2019 23:43:18 +0100
Message-ID: <87va01gv3t.fsf@mid.deneb.enyo.de>
References: <b196da6e-4614-42f9-9147-b1708c6e5094@googlegroups.com>
	<c16f6c7d-34d9-4d7e-96e6-9c00e387b2a9@googlegroups.com>
	<q66m95$8ri$1@dont-email.me>
	<a534f338-a418-424e-8043-31c738682807@googlegroups.com>
	<q68mv0$rea$1@dont-email.me>
	<a4ab4f3c-9151-47c7-9d3f-f6a23451fa0e@googlegroups.com>
	<bba8f6a8-36ce-4bed-bd84-8a9ea7dc02f7@googlegroups.com>
	<q699nu$ban$1@franka.jacob-sparre.dk>
	<87wokhk289.fsf@mid.deneb.enyo.de>
	<q7m5f7$o1k$1@franka.jacob-sparre.dk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: news.enyo.de;
	logging-data="8955"; mail-complaints-to="news@enyo.de"
Cancel-Lock: sha1:CwVgOhWT38oj0ZGU9nu7OAuK98w=
Xref: reader01.eternal-september.org comp.lang.ada:56012
Date: 2019-03-29T23:43:18+01:00
List-Id: <comp.lang.ada>

* Randy Brukardt:

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
> news:87wokhk289.fsf@mid.deneb.enyo.de...
>>* Randy Brukardt:
>>
>>> It's also possible that Ada 2020 will have a form of pointer ownership.
>>> (Unfortunately, we didn't make any conclusions on that during yesterday's
>>> meeting, so it's still in limbo, and we're getting very close to the 
>>> finish
>>> line.)
>>
>> What about other holes in the type system?  Aliasing can occur in
>> function calls even without pointers.
>
> No one submitted any problems in that area (and I don't see why "aliasing" 
> equates to "a hole in the type system" anyway).

It's supposed to be quite well-known (Robert A Duff recognized it in
2011 and provided the Ada 83 reference):

generic
   type Source is private;
   type Target is private;
function Conversion (S : Source) return Target;

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 : Target_Wrapper) return Target is
   begin
      M := (Sel => Source_Field, S => (S => S));
      return T.T;
   end Convert;
   
begin
   return Convert (M.T);
end Conversion;

> Personally, I don't think it is possible to meet the goals for efficiency 
> without aliasing -- one would have to eliminate things like by-reference 
> parameter passing and techniques like lookup indexes to avoid aliasing.

It might be sufficient to check for aliasing when passing parameters
and raise Program_Error.

> That sort of thing is pointless, at least when performance
> (time/space/power) matter.

We'll see how Rust works this out over the coming years.