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!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Bad influence of private part on what subprograms can be defined
Date: Mon, 9 Oct 2017 09:25:52 +0200
Organization: Aioe.org NNTP Server
Message-ID: <orf8a1$oc2$1@gioia.aioe.org>
References: <orea6h$1fva$1@gioia.aioe.org>
NNTP-Posting-Host: lKHBldubgAWx1EqbQpQ5LQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
X-Notice: Filtered by postfilter v. 0.8.2
Content-Language: en-US
Xref: news.eternal-september.org comp.lang.ada:48401
Date: 2017-10-09T09:25:52+02:00
List-Id: <comp.lang.ada>

On 09/10/2017 00:52, Victor Porton wrote:
> The following does not compile:
> 
> $ gnatmake -gnat2012 test
> gcc-7 -c -gnat2012 test.adb
> test.adb:18:20: subprogram "X" overrides inherited operation at line 21
> gnatmake: "test.adb" compilation error
> 
> 
> -- test.adb
> procedure Test is
> 
>    package A is
>      type A_Type is tagged null record;
>      not overriding procedure X(Object: A_Type);
>    end;
> 
>    package body A is
>      procedure X(Object: A_Type) is
>      begin
>        null;
>      end;
>    end;
> 
>    package B is
>      type B_Type is tagged private;
>      not overriding procedure X(Object: B_Type);
>    private
> --     type B_Type is tagged null record;
>      type B_Type is new A.A_Type with null record;
>    end;
> 
>    package body B is
>      procedure X(Object: B_Type) is
>      begin
>        null;
>      end;
>    end;
> 
> begin
>    null;
> end;
> 
> 
> So private part badly influences what can and what can and what cannot be
> done in the public part. Private must be private!

Yes, but it does not apply here. B has full visibility on B_Type. There 
is nothing private about how B is going to implement B_Type. An 
implementation that inherits from A_Type is incorrect when X is not from 
the class (not overriding) and the compiler dully states that.

When you qualify X as type-specific (not overriding) you wanted exactly 
that sort of check.

Note that the situation would be different if A were a private package. 
Then of course the public part of B should be free to declare X 
independently on private A_Type. Then there would be a problem with 
clients that could see both A and privates of B. But AFAIK this kind of 
scenario is impossible to construct.

> Really bad!

I don't see anything bad here. There are bad cases, e.g. private 
interfaces and others, but this one is OK to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de