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!news.eternal-september.org!.POSTED!not-for-mail
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Newsgroups: comp.lang.ada
Subject: Re: Interest in standard smart pointers for Ada 2020
Date: Sun, 3 Sep 2017 13:18:45 +0200
Organization: A noiseless patient Spider
Message-ID: <oogo6d$jul$1@dont-email.me>
References: <oo8u6r$3va$1@dont-email.me> <oo90jl$1p3p$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 3 Sep 2017 11:14:21 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="264cc8e4f0419959d3e4d0a436b64d04";
	logging-data="20437"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19hEuv4qfymDvtHovrRSK4x"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
In-Reply-To: <oo90jl$1p3p$1@gioia.aioe.org>
Content-Language: en-US
Cancel-Lock: sha1:PE/7/9Xq/9Tu12EDI023HIzYpMg=
Xref: news.eternal-september.org comp.lang.ada:47907
Date: 2017-09-03T13:18:45+02:00
List-Id: <comp.lang.ada>

On 31/08/17 14:48, Dmitry A. Kazakov wrote:
> On 31/08/2017 14:12, Alejandro R. Mosteo wrote:
> 
> [...]
> 
> My major concern is to have an ability to keep the target type private. 
> To me smart pointers are useless otherwise.

Wouldn't that be up to the instantiation? If you use a private type 
there, it will be private, right?

> Note that this preempts discussion about implicit dereference. Apart 
> from that smart pointer must be non-limited there should be no visible 
> dereference because the target type is private.

If I'm interpreting correctly, you mean that you'd want no visible 
dereference (hence implicit dereference) but that that's impossible for 
a non-limited pointer with a private target type.

I was thinking something along the following, which indeed requires the 
use of explicit getters to get a limited type that actually uses 
implicit dereference:

https://bitbucket.org/amosteo/rxada/src/361d4e2ab20a7dcca007e31bf7094d57b13fee6b/src/priv/rx-tools-shared_data.ads?at=default&fileviewer=file-view-default

Which is my adaptation and borking of 
http://www.adacore.com/adaanswers/gems/gem-107-preventing-deallocation-for-reference-counted-types/

My understanding was that you cannot make safe implicit dereferences 
with a non-limited type, but on re-reading that gem I'm unsure I grasp 
all the subtleties in there, so my code is probably not as safe as I 
thought.

>> I'd argue for having these, and also thread-safe implementations (that 
>> I guess would be heavier, requiring protected internals).
> 
> That depends on the safety meant here. If only pointer operations 
> considered, not the operations delegated to the target type operations, 
> then no protected object is required. Atomic increment and atomic 
> fetch-and-decrement are sufficient. Needless to say that Ada must have a 
> system package with these.

I meant the same as interpreted, the pointer operations.

Which doesn't preclude that I sometimes have wished to be able to do:

--  type X is private;
type X is protected private;

That would give me a vanilla protected object without having to rewrite 
everything. I know there are reasons why this is not so easy for Ada, 
but one can dream.