Re: Unchecked_Deallocation with tagged types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2022-04-16 05:44, Thomas wrote:
> In article <s5h0o5$1piu$1@gioia.aioe.org>,
>   "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On 2021-04-18 11:09, Jeffrey R. Carter wrote:
>>> On 4/18/21 10:46 AM, Gautier write-only address wrote:
>>>> Side note: did anyone already suggest a new keyword: unchecked_free
>>>> and a special statement:
>>>>
>>>>     unchecked_free Some_Pointer;
>>>
>>> For every access variable P, there could exist the attribute procedure
>>>
>>>     P'Free;
>>
>> I like the idea of attaching it to a variable rather than to type.
> 
> why?

Because operations apply to objects not to
the types of.

> if it had to be made, i would say it could not be less than sth like:
> T'Unchecked_Free (P)

This does as little sense as T'Image did.

>> I remember the claim that originally making it a generic procedure with
>> an indigestible name was meant as barrier for lazy programmers.
> 
> not only that:
> i agree J-P. Rosen (he didn't said exactly that),
> it's fine to be able to search for the "Unchecked" keyword, to look at
> parts of code with some known risk (afaik):
> Ada.Unchecked_Deallocation, Ada.Unchecked_Conversion, Unchecked_Access.

You can search for "Free" as easily.

Furthermore, the way unchecked stuff breaks the program is such that the 
actual problem is almost never located at the place where you call 
something unchecked. The error is usually triggered in a different place.

>> Plus
>> some considerations regarding garbage collection lurked in the subconscious.
> 
> could you explain, please ? :-)

You allocate objects at will and the language per magic wand frees them 
for you someway someday. This anything that works in a non-magical way 
(read: deterministic, predictable, explicit) is so outrageous that must 
be highlighted as "unchecked." (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de