Re: String_Access in unbounded string handling?

[Blady <p.p11@orange.fr>]

Le 19/01/2024 à 02:36, Randy Brukardt a écrit :
> "Tucker Taft" <tucker.taft@gmail.com> wrote in message
> news:afd791fa-853f-48fa-9223-759b12d4ed87n@googlegroups.com...
> On Sunday, January 14, 2024 at 6:05:45?AM UTC-5, Blady wrote:
>>> Hello,
>>>
>>> String_Access is defined in A.4.5 Unbounded-Length String Handling:
>>> 7 type String_Access is access all String;
>>>
>>> and note:
>>> 75 The type String_Access provides a (nonprivate) access type for
>>> explicit processing of unbounded-length strings.
>>>
>>> I wonder what String_Access is for and what could be "explicit
>>> processing"?
>>
>> The idea was to support the explicit use of new String'(...), X.all, and
>> Unchecked_Deallocation
>> rather than the implicit use of the heap inherent in Unbounded strings.  It
>> was recognized that you
>> need a single global access type to avoid having to do conversions all over
>> the place.  This
>> predated the availability of stand-alone objects of an anonymous access
>> type
>> (aka "SAOOAAATs" ;-), but those are not universally loved either.  It
>> certainly cannot be
>> removed now without potentially very painful disruption of existing users.
>> 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.
> 
> I'm dubious that there are any such users. Certainly, in the handful of
> cases where I needed such a type, I just declared it (strong typing, you
> know?) and never thought of Ada.Strings.Unbounded as being a place to find
> such a type already defined. It is such an odd place I doubt anyone outside
> of perhaps the people who defined the type ever used it.
> 
> OTOH, I agree that the compatibility impact is non-zero (anyone who did use
> it would have to change their code), and the benefit of removing the type at
> this point is close to zero (junk declarations abound in long-term Ada
> packages, what's one more; and certainly there is a lot of unused stuff in
> any particular reusable package and any particular use), so the cost-benefit
> ratio doesn't seem to make a change here worth it. An Ada successor language
> would design Ada.Strings.Unbounded rather differently (so as to be able to
> use string literals directly with the type) and probably would include
> universal character support as well, so it's hard to find an important
> reason to change this.

At least, the type String_Access could be tagged as obsolescent.

Pascal.