CVS difference for ais/ai-20217.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-20217.txt

--- ais/ai-20217.txt	2001/10/02 01:27:52	1.3
+++ ais/ai-20217.txt	2001/10/02 20:50:32	1.4
@@ -1709,3 +1709,117 @@
 
 *************************************************************
 
+From: Dan Eilers
+Sent: Tuesday, October 2, 2001,  1:37 PM
+
+Would the type safety problems associated with multiple bindings
+of type stubs be avoided by prohibiting the use of the type stub
+as anything other than a stub, even after being bound?
+If so, this would eliminate the need for cumbersome post-compilation
+rules attempting to prevent multiple bindings across independent
+partitions within a program.
+
+Slightly modifying Randy's example where noted:
+
+    package Interface is
+       type Stub is tagged separate;
+    end Interface;
+
+    with Interface;
+    package Complete1 is
+       type Tag1 for Interface.Stub is tagged record
+          F : Float;
+       end record;
+    end Complete1;
+
+    with Interface;
+    package Complete2 is
+        type Tag2 for Interface.Stub is tagged record
+           I : Integer;
+        end record;
+    end Complete2;
+
+    with Interface;
+    procedure Do_Something (A : in Interface.Stub);
+
+    with Interface, Complete1;
+--  procedure Do_Something (A : in Interface.Stub) is
+    procedure Do_Something (A : in Complete1.Tag1) is  -- conformant
+    begin
+       if A.F = 1.0 then -- (1)
+       ...
+    end Do_Something;
+
+    with Interface, Complete2, Do_Something;
+    procedure Problem is
+       T : Complete2.Tag2;
+    begin
+         Do_Something (T); -- (2)  -- compile-time type clash: Tag2 vs. Tag1
+    end Problem;
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, October 2, 2001,  2:29 PM
+
+I don't see how that would help.  You're generally going to want to
+have access types that designate the stub type, and there's no way
+of preventing accesses from denoting objects of differing full types
+if you allow multiple full types.  The limitation to one full type
+per type stub is a fundamental restriction as far as I can see.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 2, 2001,  2:24 PM
+
+That was my original idea. But the rules for doing that are rather messy, and
+it makes these very much harder to use, so I abandoned it. (Note that the
+original name of the AI mentioned in the agenda is "forever incomplete types").
+
+Among other things, we would have to invent a series of horrible type
+conversion rules (in that model, the incomplete type has to be a completely
+separate type); to make this work reasonably, they have to be implicit
+conversions. Worse, it means that an access type which designates a separate
+incomplete type could never have an allocator (as there would be no place where
+such an allocator could be used). And that means that users would have to use
+explicit conversions (or 'Access, they're equivalent) to use such a type. That
+is one of the major reasons that "with type" was abandoned, and I was quite
+unwilling to introduce it into this proposal.
+
+No matter what the model, it's important to remember that "separate incomplete
+types" or whatever they end up being called need to be usable. Restrictions on
+the use of the type certainly harm the usability.
+
+---
+
+In your example:
+
+    with Interface;
+    procedure Do_Something (A : in Interface.Stub);
+
+    with Interface, Complete1;
+--  procedure Do_Something (A : in Interface.Stub) is
+    procedure Do_Something (A : in Complete1.Tag1) is  -- conformant
+    begin
+       if A.F = 1.0 then -- (1)
+       ...
+    end Do_Something;
+
+    with Interface, Complete2, Do_Something;
+    procedure Problem is
+       T : Complete2.Tag2;
+    begin
+         Do_Something (T); -- (2)  -- compile-time type clash: Tag2 vs. Tag1
+    end Problem;
+
+I don't see why you'd have a type clash here: the specification of Do_Something
+clearly specifies Stub, which has to match either type. Without seeing the
+body, you don't know which is meant. Surely you can't be suggesting some sort
+of body dependence; it is too much dependence that we are trying to get away
+from (keep in mind that Do_Something could have been defined in Interface
+itself, and a body dependence then would essentially reintroduce the problem
+we're trying to get around).
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent