From mboxrd@z Thu Jan 1 00:00:00 1970 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Blady Newsgroups: comp.lang.ada Subject: Re: String_Access in unbounded string handling? Date: Tue, 30 Jan 2024 16:53:22 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 30 Jan 2024 15:53:23 -0000 (UTC) Injection-Info: dont-email.me; posting-host="98e9d514af18df5c5d5a35536286b84d"; logging-data="1112608"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+M9otq9EmFIGySlrPQs0hs" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:bJ6f9PLalxlljsKhsUEmiPsuCLQ= In-Reply-To: Content-Language: fr, en-US Xref: news.eternal-september.org comp.lang.ada:66047 List-Id: Le 19/01/2024 à 02:36, Randy Brukardt a écrit : > "Tucker Taft" 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.