On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote:
>On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
>You can find the final draft of the high-level goals for the D programming language at the following link:
Under 'Memory safety':
>Allow the continued use of garbage collection as the default memory management strategy without impact. The GC is one of D's strengths, and we should not "throw the baby out with the bath water".
Under 'Phobos and DRuntime':
>@nogc as much as possible.
Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library.
@nogc
code in Phobos still allows the use of the GC in client code. Those are not opposite goals.
Then it's not part of D's strengths.
No, that's not what that means. When Phobos was originally implemented, @nogc
wasn't a thing. There was no (or little) consideration given to whether a particular function absolutely needed to use the GC, or if there was an alternative. And later on, as demand grew for more @nogc
support, that had to be bolted on.
So what the @nogc as much as possible
goal means is that it should be a consideration for the implementation of Phobos v2 from the beginning. The design of the API should allow @nogc
client code to make use of it as much as possible.
GC is a strength, but it's not a panacea. There are specific cases where people determine it's better to avoid it, and there are some people who don't want to use it at all. As long as we continue to support @nogc
in the language, then we ought to provide support for it in Phobos to the extent that we can. The vision document is just making it clear that this will be a goal from the beginning with v2.