The D standard library is built on GC, is that a negative or positive?

[Tejas]

On Sunday, 18 December 2022 at 22:11:21 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 17 December 2022 at 18:44:21 UTC, IGotD- wrote:
>> [...]
>
> I wouldn't say it is is the only choice. If D was willing to 
> make a bold move towards modelling software as short lived 
> actors/tasks then you could use arenas that typically don't 
> collect, but is wiped out when the task is done (collection 
> only happens if you run out of memory).
>
> Right now I am personally more interested in Carbon that will 
> be 100% GC free. I like that they take a stance on memory 
> management overhead. There are also interesting things going on 
> in the research field with separation logic and similar 
> formalizations, still probably 20 years until it will be 
> generally useful, but things are moving IMO. There is also some 
> interest in memory pools/arenas in the C++ community I think, 
> and there seems to be an interest in Apple for integrating C++ 
> and Swift, so maybe pairing one managed and one unmanaged 
> language is the way forward, short term. So overall, the global 
> picture is nuanced.
>
>> [...]
>
> Application specific collectors don't have to do all this work 
> as they will only collect at specific points where the state is 
> known and where the number of live objects are minimal. This is 
> something one should be able to use verification technologies 
> for, basically proving that there are no stray references 
> hanging around when you start collecting. Rust is only the 
> beginning I think.
>
>> [...]
>
> You could probably generate a hardcoded "optimal" scanner 
> statically at linktime after LTO, but that only makes it 
> somewhat faster, and not really better.
>
>> [...]
>
> Suspending all threads, for whatever reason, is a terrible 
> idea. Just think about Amdahl's law:
>
> https://en.wikipedia.org/wiki/Amdahl%27s_law#/media/File:AmdahlsLaw.svg
>
>> [...]
>
> ARC.

When all is said and done, I think we should try to provide 
lifetimes as a feature, simply because [C++ might be offering 
them](https://www.reddit.com/r/cpp/comments/ttw0dl/ruststyle_lifetimes_proposed_in_clang/), and we will need to accomodate  that for the sake of C++ interop anyways, else risk deteriorating our C++ interop story

I know having a proposal means very little, but I have a feeling 
that it's a question of when, not if, C++ receives lifetime 
annotations