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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,9983e856ed268154
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.236.83.111 with SMTP id p75mr10989147yhe.5.1344998912527;
        Tue, 14 Aug 2012 19:48:32 -0700 (PDT)
Path: 
 c6ni115625004qas.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin2!goblin.stu.neva.ru!news.teledata-fn.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 10 Aug 2012 10:12:35 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Should Inline be private in the private part of a package spec?
References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net>
 <e416cb92-6ec8-4514-8fa9-c35d6432b117@googlegroups.com>
 <wcc4noj4zof.fsf@shell01.TheWorld.com> <jvnchp$r5c$1@munin.nbi.dk>
 <wccr4rkqed5.fsf@shell01.TheWorld.com> <op.wiml9rw3ka8ora@aspire.local>
 <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net>
 <op.wim0pbprka8ora@aspire.local>
 <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net>
 <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net>
 <k01amo$jio$1@munin.nbi.dk>
In-Reply-To: <k01amo$jio$1@munin.nbi.dk>
Message-ID: <5024c273$0$6557$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 10 Aug 2012 10:12:35 CEST
NNTP-Posting-Host: 334fa1ed.newsspool4.arcor-online.net
X-Trace: 
 DXC=1oeCJCAE\3m_0Po7BmQ3]l4IUK<Cl32<a4Fo<]lROoRa8kF<OcfhCOkhn@@Y2U:<lnPCY\c7>ejVh5O0D9HAUC4eIN?FDJmHbka
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-08-10T10:12:35+02:00
List-Id: <comp.lang.ada>

On 09.08.12 23:39, Randy Brukardt wrote:

>>   it is not important to know
>> the convention of an import when writing the call (of the
>> Ada subprogram from the package spec).
>
> This is definitely not true. The convention affects legality as well as code
> generation.

Just saying that legality may or may not appear on the programmer's radar,
depending on whether he or she declares a subprogram pointer type, say.
The compiler's error message might be surprising otherwise, the one about
the subprogram pointer type needing the same convention as the subprogram.

Another impressive case,

   function New_T (X : Integer; this : T_Ptr := null) return T_Ptr
      with Convention => Java_Constructor;

Thinking of SofCheck's (now AdaCore's) or AdaCore's (still AdaCore's)
Ada->JVM translators. The convention here really makes all client
programmers aware that everything at or near New_T needs special
attention. "All" is slightly more than 1% wishing to compile without
the help of a computer program ;-)

Elsewhere:
> The*only*  thing here should be an implementation-independent indicator of
> how this should be used

Much better wording than what I had. I'd add to your assessment of the
use of Inline that if it should be present at all, it should give
control to the user, not permission to the compiler; as it is now,
Inline cannot be used to prevent inlining, so the programmer cannot
control inlining with the help of Inline.