Refactoring a "simple" function in dmd source

[Hipreme]

On Sunday, 31 December 2023 at 19:09:15 UTC, Walter Bright wrote:
> On 12/31/2023 5:02 AM, Siarhei Siamashka wrote:
>> Or more like 
>> https://dlang.org/library/std/string/line_splitter.html for 
>> having no allocations and `@nogc` compatibility.
>
> I missed the existence of that. Oops!
>
>> The listed benefits are nice and very much welcome, but it's a 
>> copy-paste job from Phobos into the DMD codebase. Raising a 
>> question again about the reasons why DMD itself isn't using 
>> Phobos like any normal applications do.
>
> It's good to question decisions now and then, but we just had a 
> conversation about it.
>
>> Also whenever game developers are complaining in this forum 
>> about poor `@nogc` support, they are being told that the GC is 
>> totally fine and they are just unreasonably biased against it. 
>> All of this while the DMD compiler itself is doing fancy 
>> hackish stunts with memory allocation. Games are latency 
>> sensitive. Compilers are not.
>
> GC is just another tool. There are places where it is 
> appropriate, and places where it is not. Because some functions 
> in Phobos use GC does not mean anyone using Phobos must use GC, 
> not at all.
>
> Problems also exist if Phobos was to use malloc(). In 
> particular, who owns the memory thus allocated?
>
> Finding a method that avoids allocation entirely resolves this 
> conundrum rather neatly.


Not on a completely unrelated note. But I wanted to say that in 
newer versions we could have memory reserve/preAllocate inside 
range interfaces. I've been using that on output ranges since it 
could decrease the number of allocations required on output 
ranges, thus increasing performance.

For example: when converting a integer to a string, I calculate 
first how many digits the string will need, after that, I 
preallocate the digits count and only after that I start 
outputting it.