From mboxrd@z Thu Jan  1 00:00:00 1970
X-Received: by 2002:a05:6214:2482:b0:681:55b6:1e40 with SMTP id gi2-20020a056214248200b0068155b61e40mr957269qvb.4.1705498453265;
        Wed, 17 Jan 2024 05:34:13 -0800 (PST)
X-Received: by 2002:a81:72c1:0:b0:5fb:7b86:db34 with SMTP id
 n184-20020a8172c1000000b005fb7b86db34mr4634829ywc.4.1705498452881; Wed, 17
 Jan 2024 05:34:12 -0800 (PST)
Path: eternal-september.org!news.eternal-september.org!feeder3.eternal-september.org!weretis.net!feeder6.news.weretis.net!border-2.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 17 Jan 2024 05:34:12 -0800 (PST)
In-Reply-To: <uo0f65$dlcm$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=74.104.185.8; posting-account=PvmV9AoAAAD6m3XXwubwsbGwa7cDXv1N
NNTP-Posting-Host: 74.104.185.8
References: <uo0f65$dlcm$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <afd791fa-853f-48fa-9223-759b12d4ed87n@googlegroups.com>
Subject: Re: String_Access in unbounded string handling?
From: Tucker Taft <tucker.taft@gmail.com>
Injection-Date: Wed, 17 Jan 2024 13:34:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:66000
List-Id: <comp.lang.ada>

On Sunday, January 14, 2024 at 6:05:45=E2=80=AFAM UTC-5, Blady wrote:
> Hello,=20
>=20
> String_Access is defined in A.4.5 Unbounded-Length String Handling:=20
> 7 type String_Access is access all String;=20
>=20
> and note:=20
> 75 The type String_Access provides a (nonprivate) access type for=20
> explicit processing of unbounded-length strings.=20
>=20
> I wonder what String_Access is for and what could be "explicit processing=
"?=20

The idea was to support the explicit use of new String'(...), X.all, and Un=
checked_Deallocation rather than the implicit use of the heap inherent in U=
nbounded strings.  It was recognized that you need a single global access t=
ype to avoid having to do conversions all over the place.  This predated th=
e availability of stand-alone objects of an anonymous access type (aka "SAO=
OAAATs" ;-), but those are not universally loved either.  It certainly cann=
ot be removed now without potentially very painful disruption of existing u=
sers.  It could be moved to a different package without too much disruption=
, but I haven't seen any groundswell of interest in doing that either.
>=20
> Thanks, Pascal.

Take care,
-Tuck