# Worries about the future with what adacore has in store **URL:** \ **Category:** General\ **Created:** [August 27, 2024, 11:01am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123 "2024-08-27T11:01:39Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 27, 2024, 11:01am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/1 "2024-08-27T11:01:39Z")
Hi, I watched [High Integrity Technology Update | April 2024](https://www.youtube.com/watch?v=UX5_ub0Sw88) and almost got a heart attack. Four things, which I memefied to better convey my feelings, appalled me. Pattern matching I could see the interest… even thoug they didn’t provide a single convincing use case yet. But the rest ? Constructors ? String interpolation ? _ **Classes** _ ? These things never had anything to do in Ada, were never needed, or were explicitely rejected from the very early beginning, in favor of a cleaner design that did not blend orthogonal notions such objects and encapsulation. I might be a beginner, but I’m 30, with common sense, a degree in history and notions of psychology. I believe the situation is identical to a story 10 to 15 years ago, with an exacting but consistent natural diet, with sound principles, that wasn’t appealing to many people because it demanded from its practionners discipline and thinking differently. Then to make more bucks the people which due to circumstances got a virtual monopoly on the brand opted to align themselves with mainstream dietetics in language, something already worrying… then remove all meat from their catalogue to please their prospective vegan customers… then add bloody _vitamin complements_. To appeal to the mythical larger audience. Adacore is defiling Ada. We like it because of the philosophy, because and not in spite of it. “string interpolation” belongs to bash scripts. Just to avoid writing a few 'Image, seriously ? It’s pointless as well: why would C or C++ programmers bother with a botched C++ clone with lots of verbuous English and a dearth of libraries, when they have the real deal and access to a world of existing C/C++ projects ? ![ada_meme](https://forum.ada-lang.io/uploads/default/original/1X/d1572bf4b2cf7bf2ed90d53325e4667eeaef8ae3.jpeg) ---
**Author:** ![AJ-Ianozi](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/aj-ianozi/32/39_2.png) [@AJ-Ianozi](https://forum.ada-lang.io/u/AJ-Ianozi)\ **Post date:** [August 27, 2024, 3:36pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/2 "2024-08-27T15:36:01Z")
The only one I vehemently disagree with here is local variables without the declare block. I think it’s confusing and actively goes against the philosophy of the language. I’m actually excited about pattern matching and have been following [the rfc](https://github.com/AdaCore/ada-spark-rfcs/blob/25a9a4b42b2835deb4125ac8f739d047bec64e59/prototyped/rfc-pattern-matching.rst) with baited breath. It’s something that would have made my life easier with things like parsers and one argument against using Ada I’ve heard is that it doesn’t have pattern matching at the level of other languages. Maybe now I can stop nesting switch statements. Tagged types in ada always felt hacky for me. I use them heavily and always felt it kind of weird that I had to have procedures that are accessible via the dot-operator had to be directly after the type’s finished definition, because now I’m structuring my header files in rigid ways. At least if they move to this actual OOP syntax, I can nest the dang things correctly into the type and properly scope those functions to the type. I’m not against string interpolation, and could go either way as long as I’m not taking a performance hit (strings in ada have always felt incredibly fast). It depends on which of the following lines of code you’d rather have: ```ada Put_Line ("The name is " & Name & " and the sum is " & Integer(X + Y)'Image & "."); ``` vs ```ada Put_Line (f"The name is {Name} and the sum is {X + Y}."); ``` I’m neutral with constructors and destructors; we already have controlled types so I’m not sure what the use case is. I have over 20 “from\_” [in my money library](https://github.com/AJ-Ianozi/Cashe/blob/bd39bb28d61c6fc32b411d82c5951065aa109e34/src/cashe-money_handling.ads#L585) with tons of various overriding and I guess using something like T1’Make(…) instead could work. I’d rather be explicit though. I hope these constructors are at least using the stack… P.S. When I read the title, I thought you were going to complain about things like this: > **[AdaCore Join Rust Enthusiasts in Paris](https://blog.adacore.com/adacore-join-rust-enthusiasts-in-paris)** > > by Jose Ruiz – Aug 21, 2024. On June 25th, I attended the Rust Paris 2024 conference. Among around one hundred Rust enthusiasts and a program filled with captivating subjects and contributors, I presented (together with Thales) our vision for... ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 27, 2024, 7:50pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/3 "2024-08-27T19:50:13Z")
Actually I read that a few hours later 🤣 I see they’ve been pandering to all kinds of trendy languages for many years by now. But while typically those efforts fail lamentably, I wouldn’t mind their business practices wouldn’t bother me much if they treated the language with more respect. ```ada Put_Line ("The name is " & Name & " and the sum is " & Integer(X + Y)'Image & "."); ``` Yes this above is much clearer than showing {} inside, and that new “f” completely at odd with the rest. I’m absolutely certain no serious or long term Ada programmer ever wished for whatever they brought in, imitating whichever unprofessional functional or script language. I think the need for constructors must parallel the removal of controlling returns… but then we loose flexibility. An aspect would suffice to indicate a controlling result/constructor status, there is no need to ape C++. They just aim to make a more marketable product, or so they think. ---
**Author:** ![bracke](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/bracke/32/19_2.png) [@bracke](https://forum.ada-lang.io/u/bracke)\ **Post date:** [August 28, 2024, 6:40am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/4 "2024-08-28T06:40:42Z")
Well I guess that means I’m not a serious programmer, clearly 30 years is not enough experience. I prefer the string interpolation way both for readability and for ease of use. ---
**Author:** ![Shuihuzhuan](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/s/c6cbf5/32.png) [@Shuihuzhuan](https://forum.ada-lang.io/u/Shuihuzhuan)\ **Post date:** [August 28, 2024, 9:29am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/5 "2024-08-28T09:29:55Z")
I personnaly dislike both syntax. - Strings constructions like `"The name is " & Name & " and the sum is " & Integer(X + Y)'Image & "."` are not translatable. - Interpolated strings can’t be translated also. Outside debugging, I can’t see a use case for such syntaxes. ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 9:39am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/6 "2024-08-28T09:39:05Z")
> [@bracke](#): > > Well I guess that means I’m not a serious programmer, clearly 30 years is not enough experience. I just spoke my mind, no offense. I attack dangerous opinions, not people… One can be brilliant and wrong. I just can’t understand “fixing” something that’s not broken for a very strange sense of convenience. Perhaps you have been taught on other languages or used them preferently ? > Interpolated strings can’t be translated also What do you mean by translatable ? Like, from English to French ? Or one unicode format to another ? ---
**Author:** ![Shuihuzhuan](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/s/c6cbf5/32.png) [@Shuihuzhuan](https://forum.ada-lang.io/u/Shuihuzhuan)\ **Post date:** [August 28, 2024, 9:52am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/7 "2024-08-28T09:52:40Z")
I mean translated to the language of the user (french, chinese…). ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 10:50am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/8 "2024-08-28T10:50:51Z")
Thought so. What does that have to do with syntax, and what’s wrong with this ```Ada type Lang is (French, English, Chinese, Mandalorian); function Translate (English : String; Current_language: Lang) return String; ``` ---
**Author:** ![Shuihuzhuan](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/s/c6cbf5/32.png) [@Shuihuzhuan](https://forum.ada-lang.io/u/Shuihuzhuan)\ **Post date:** [August 28, 2024, 11:58am UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/9 "2024-08-28T11:58:36Z")
This doesn’t work in practice with interpolated strings. The f-string is first read as a `Wide_Wide_String`, processed, interpolated and then converted to the expected type, a `String` in your example ([link to the RFC](https://github.com/AdaCore/ada-spark-rfcs/blob/25a9a4b42b2835deb4125ac8f739d047bec64e59/prototyped/rfc-string-interpolation.md)). Finally, the result of the interpolation is passed to the `Translate` function. Good luck to do something useful with it in the function. Most translation tools use catalogs of (complete sentence) strings with placeholders for parameters to be replaced. A string is first translated and then processed, not the contrary. And it’s already hard to do good translations that way… ---
**Author:** ![JC001](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/j/e56c9b/32.png) [@JC001](https://forum.ada-lang.io/u/JC001)\ **Post date:** [August 28, 2024, 1:10pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/10 "2024-08-28T13:10:19Z")
The problem with mingling declarations and executable statements is what can be referenced in exception handlers. No doubt AdaCore have a rule about that for their language extension, but I can’t conceive of one that would make the combination of this feature and exception handlers useful. Added to the fact that such mingling makes the code more difficult to understand, by making declarations harder to find, and I can see no case for allowing this. ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 1:15pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/11 "2024-08-28T13:15:09Z")
No I mean with the normal strings. Of course translation tools would use dictionaries. Otherwise you would need a real automatic translation with an LLM… What else would you expect ? My only grip with String is the limitation to ISO-8859-1 there is in GNAT, so that you can’t naturally just write ‰碱螽 in it like you can do in almost every graphical application on linux now (ctrl-u). `gnatmake` works fine, but `alr run` suffers from the same issue too, even though it’s not graphical… go figure. We should be able to write any unicode symbol in string literals and comments, and the compiler should figure out itself what kind of character it should be, normal or wide or wide wide. ---
**Author:** ![jere](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/jere/32/87_2.png) [@jere](https://forum.ada-lang.io/u/jere)\ **Post date:** [August 28, 2024, 1:32pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/12 "2024-08-28T13:32:48Z")
> [@AJ-Ianozi](#): > > I’m neutral with constructors and destructors; we already have controlled types so I’m not sure what the use case is. I think the main use case (aside from being familiar to others from other languages) is adding construction/destruction to existing tagged types. Since they already have a base type you cannot extend them off of any controlled type. There are all work around but all have some kludge aspect to them and don’t fully provide the desired full functionality. Also, if you dislike inheritance altogether (a lot of folks dislike it), having attribute or aspect based constructors/destructors is really nice. It means you aren’t forced to use inheritance that you would not otherwise have needed. ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 1:50pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/13 "2024-08-28T13:50:33Z")
Could you provide an exemple of something normal functions or a mixin and an access discriminant can’t easily do ? I could learn a thing or two 🙂 ---
**Author:** ![jere](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/jere/32/87_2.png) [@jere](https://forum.ada-lang.io/u/jere)\ **Post date:** [August 28, 2024, 1:54pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/14 "2024-08-28T13:54:38Z")
Normal functions aren’t called automatically like Initialize and Finalize are. A Mixin doesn’t allow you to properly add them so that future descendants can also override them. Additionally using a mixin can cause some logic errors/bugs because a mixin would only call Finalize during the component finalization process meaning you could run into cases where components of descendants where already finalized prior to your Finalize being called, meaning your finalize could be operating on already finalized variables. See: [Extending a third party tagged type while adding finalization - Jere](https://usenet.ada-lang.io/comp.lang.ada/4db43571-7f86-4e73-8849-c41160927703@googlegroups.com/) In particular: > [@](#): > > On Tuesday, November 28, 2017 at 6:48:10 AM UTC-5, AdaMagica wrote: > > > Am Montag, 27. November 2017 20:53:59 UTC+1 schrieb Jere: > > > > > The output for this is: > > > Initialize C1 > > > Initialize Final > > > Initialize C2 > > > Starting > > > Finalize C2 > > > Finalize Final > > > Finalize C1 > > > > > > which is the same thing I was seeing with my version. Final is initialized > > > before C2 and C2 is finalized before Final. > > > > Yes, that’s a side effect of the selfreference. Too bad. > > Yes indeed. This is why I initially said it couldn’t be done safely. The > self reference + dispatch causes out of order initialization and > finalization. It can be done safely in specific cases, but not > in general. I got this result from both my initial code and using the > code from your paper. It makes sense now that I have had time to > think about it more. Basically, I can add Initialization and > Finalization to a descendant, but I cannot do so in a manner that > further descendants can safely inherit it. I have to add it to each > descendant manually (and avoid the classwide self reference) to keep safety. ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 2:02pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/15 "2024-08-28T14:02:10Z")
Wouldn’t to allow initialize/etc for already existing tagged types do the same ? There’s an rfc replacing Controlled and Limited\_Control with interfaces, and another with aspects (gnat extension) but then they explicitely exclude it for non-base types… or I might be confused. ---
**Author:** ![jere](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/jere/32/87_2.png) [@jere](https://forum.ada-lang.io/u/jere)\ **Post date:** [August 28, 2024, 2:05pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/16 "2024-08-28T14:05:43Z")
> [@evanescente-ondine](#): > > But then wouldn’t fulfill the same purpose to allow initialize/etc for already existing tagged types ? They currently don’t allow this in Ada. Once you have an existing tagged type, if it wasn’t extended from a Controlled type originally you cannot add it in in an extendable manner (if you are working with 3rd party libraries). Now if Ada added a controlled interface, then that would definitely solve my problem. They haven’t and I don’t think it is currently planned (maybe it is? I haven’t checked the AI docket in a bit). But either an interface version or the atribute constructors/destructors would work for my use case (if either existed). ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 2:21pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/17 "2024-08-28T14:21:20Z")
Using the issues’ search engine isn’t easy, but it’s there, and I remember the restriction well. Gnat [extension](https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/gnat_language_extensions.html) also states it: > The Finalizable aspect can be applied to any record type […]. The only restriction is that the record type must be a root type, in other words not a derived type. ---
**Author:** ![jere](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/jere/32/87_2.png) [@jere](https://forum.ada-lang.io/u/jere)\ **Post date:** [August 28, 2024, 2:31pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/18 "2024-08-28T14:31:56Z")
I was more referring to the feature they mentioned in the video (`'Constructor` and `'Destructor`). The `Finalizable` aspect is a different thing from that. They may have the same restrictions for both, but I did not see it. It would be a shame though if they do have the restrictions on both. Also keep in mind that the issues on the github are for discussion. There’s no guarantee that any one issue gets implemented or even implemented as originally requested. For issues currently under consideration: > **[Ada Issues](http://www.ada-auth.org/ais.html#Ada2022)** > > Master site for Ada Issues In particular the `Ada 2022 Technical Corrigendum Issues` section as those are the next batch likely to make it into the language. I haven’t looked through them to see if it is in there (I cannot get zip files here easily). ---
**Author:** ![evanescente-ondine](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/evanescente-ondine/32/451_2.png) [@evanescente-ondine](https://forum.ada-lang.io/u/evanescente-ondine)\ **Post date:** [August 28, 2024, 2:40pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/19 "2024-08-28T14:40:01Z")
I was refering to these 😁. Your exemple with out-of-order initialization/finalization was very informative. I can see that one would want to fix a precise order somehow. ---
**Author:** ![jere](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/jere/32/87_2.png) [@jere](https://forum.ada-lang.io/u/jere)\ **Post date:** [August 28, 2024, 2:44pm UTC](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123/20 "2024-08-28T14:44:01Z")
Gotcha! I got confused cause your OP and meme picture were highlighting the method from the video. Sorry about that! I think I found the github issue: > > > In Ada 95 we use tagged types as the basis for various features, but as Ada has …evolved since then, we have begun to use aspects rather than extending a "magic" tagged type as a way to give special properties to certain types. There are upsides and downsides to using tagged types, but for resource-constrained embedded systems, aspect-based features can in some cases be easier to implement, and in some cases easier to verify, because class-wide types and run-time dispatching need not be part of the equation. > > In any case, here is a proposal by Romain Beguet (AdaCore engineer) from about three years ago, for a "lighter weight" finalization approach. Essentially it is substituting the use of aspects for the use of the special Ada.Finalization.\[Limited\_\]Controlled types. I am posting it here to re-open the discussion. One possibility would be to focus on the "limited" case first, where there is no user-defined assignment, but just user-defined initialization and finalization. On the other hand, if we make it a full capability feature, then probably the existing Ada.Finalization package should be relegated to the Obsolescent annex (Annex J). > > Similar arguments might be made (and have been made) for Storage\_Pools, Streams, and Iterators, but those would deserve their own Issue in any case. One could imagine a goal for the next version of Ada would be to move all features based on "magic" tagged types/interfaces over to aspects, if that were considered a generally useful shift. > > \---- > > \- Feature Name: lightweight-finalization > \- Start Date: 2020-11-23 > \- RFC PR: (leave this empty) > \- RFC Issue: (leave this empty) > > Summary > ======= > > We introduce a new finalization mechanism that does not rely on tagged types, has simpler semantics and weaker guarantees than today's controlled types in such a way that: > 1. It imposes less design constraints to users. > 2. It can be supported on broader range of platforms (e.g. embedded). > 3. It allows for an efficient implementation. > > \*Note: we abuse the term "finalization" throughout this RFC to denote control over the whole lifetime of an object, i.e. the same level of control that controlled objects provide today.\* > > Motivation > ========== > > First of all, current finalization based on controlled objects forces users to turn their untagged type into a tagged type in order for it to benefit from finalization. Thus, new legality rules apply (e.g. RM 3.9.2) which can break existing code in many different ways. One such example is illustrated below: > \`\`\`ada > type T is tagged null record; > type U is record; > > function F (X : T) return U; > \`\`\` > In this situation, one cannot simply turn \`U\` into a controlled object, otherwise the subprogram \`F\` would become a primitive of two tagged types, which is forbidden. > > Second, the guarantees provided by controlled types are very strong, requiring a complex implementation and incurring a substential runtime performance penalty. On some platform, it is extremely difficult (impossible?) to write an implementation that fulfills all those guarantees. > > One such guarantee is that an access-to-controlled type should finalize all objects that have been \*\*heap-allocated\*\* through it once it goes out of scope (\*todo: link to RM\*). The compiler must therefore generate code to keep track of these objects, untrack them upon explicit deallocation, etc., which obviously induces a significant overhead at runtime. > > For the record, GNAT already supports some custom aspects to weaken the default guarantees mandated by the Ada specification, such as \`pragma No\_Heap\_Finalization\` and \`pragma Finalize\_Storage\_Only\`. > > Guide-level explanation > ======================= > > We propose to introduce three new Ada 2012 aspects, analogous to the three controlled-type primitives, as in the following template: > \`\`\`ada > type T is ... > with Initialize =\> \, > Adjust =\> \, > Finalize =\> \; > \`\`\` > > The three procedures have the same profile, taking a single \`in out T\` parameter. > > We follow the same dynamic semantics as controlled objects: > - \`Initialize\` is called when an object of type \`T\` is declared without default expression. > - \`Adjust\` is called after an object of type \`T\` is assigned a new value. > - \`Finalize\` is called when an object of type \`T\` goes out of scope (for stack-allocated objects) or is explicitly deallocated (for heap-allocated objects). It is also called when on the value being replaced in an assignment. > > \### Examples > > A simple example of a ref-counted type: > \`\`\`ada > type T is record > Value : Integer; > Ref\_Count : Natural := 0; > end record; > > procedure Inc\_Ref (X : in out T); > procedure Dec\_Ref (X : in out T); > > type T\_Access is access all T; > > type T\_Ref is record > Value : T\_Access; > end record > with Adjust =\> Adjust, > Finalize =\> Finalize; > > procedure Adjust (Ref : in out T\_Ref) is > begin > Inc\_Ref (Ref.Value); > end Adjust; > > procedure Finalize (Ref : in out T\_Ref) is > begin > Def\_Ref (Ref.Value); > end Finalize; > \`\`\` > > A simple file handle that ensures resources are properly released (Taken from a discussion in \[this RFC\](https://github.com/AdaCore/ada-spark-rfcs/pull/29#issuecomment-539025062)) > \`\`\`ada > type File (\<\>) is limited private; > > function Open (Path : String) return File; > > procedure Close (F : in out File); > private > type File is limited record > Handle : ...; > end record > with Finalize =\> Close; > \`\`\` > > \### Heap-allocated finalized types > > As already mentioned, today's controlled objects allocated on the heap through an access type T must be finalized when T goes out of scope. First of all, we propose to completely drop this guarantee for libary-level access types, meaning program termination will not require finalization of heap-allocated types. The rationale for this is that in most cases, finalization is used to reclaim memory or release resources, which the underlying system (if any) generally does regardless upon program termination. As for baremetal platforms, heap allocation is either not available/allowed (meaning this is a non-issue) and if it is, we assume that manual deallocation is required and therefore finalization will be properly executed. > > As for nested access-to-finalized types, there are at least two simple ways to reason about them: > - Don't do anything when such an access type goes out of scope: it is the responsibility of users to finalize their object, much like it is their responsibility to free the memory. > - Forbid such access types for now, until we have enough tools (such as an ownership system) to ensure that objects allocated through those access types are properly free'd (and therefore their finalize procedures properly called). > > \### Finalized tagged types > > We propose that aspects are inherited by derived types and optionally overriden by those. The compiler-generated calls to the user-defined operations should then be dispatching whenever it makes sense, i.e. the object in question is of classwide type and the class includes at least one finalized-type. > > \### Composite types > > When a finalized type is used as a component of a composite type, the latter should become finalized as well. The three primitives are derived automatically in order to call the primitives of their components. If that composite type was already user-finalized, we propose that the compiler calls the primitives of the components so as to stay consistent with today's controlled types's behavior. So, \`Initialize\` and \`Adjust\` are called on components before they are called on the composite object, but \`Finalize\` is called on the composite object first. This is the easiest approach as it avoids confusing users and its semantics are already battle-tested, but could still be revised. > > \### Interoperability with controlled types > > In order to simplify implementation, we propose to initially forbid any of these new aspects on a controlled-type, components of a controlled type, composite types of which any part is controlled and interfaces which are derived by a controlled type. > > \### Constant objects with finalization > > The profile suggested above for the three primitives takes an \`in out\` parameter. How should we handle constant objects of a finalized type? > > First, note that \`Initialize\` is out of the equation since constant object require explicit initialization. \`Adjust\` is also out because constant objects obviously cannot be reassigned to. We are therefore left with \`Finalize\`. We could either take the same approach as controlled-types and let the parameter be \`in out\`, or we could introduce a new aspect \`Finalize\_Constant\` that is called in-place of \`Finalize\`, which takes an \`in\` parameter instead. In this scenario, we suggest a warning could be emitted if a type specifies \`Finalize\` but does not specify \`Finalize\_Constant\` and a constant object of that type is declared. > > Drawbacks > ========= > > Since this partly overlaps with controlled-types, new users could get a bit lost. > > Prior art > ========= > > TBD. Talk about RAII in languages such as C++. But it does allow for derived types. > [@](#): > > ### Finalized tagged types > > We propose that aspects are inherited by derived types and optionally overriden by those. The compiler-generated calls to the user-defined operations should then be dispatching whenever it makes sense, i.e. the object in question is of classwide type and the class includes at least one finalized-type. But maybe the discussion for the issue addresses a change in that. I didn’t read through fully yet. [Next page](https://forum.ada-lang.io/t/worries-about-the-future-with-what-adacore-has-in-store/1123.md?page=2)