Phobos 3 Discussion Notes - 02-01-2024

[Atila Neves]

On Monday, 12 February 2024 at 19:49:39 UTC, Paul Backus wrote:
> On Monday, 12 February 2024 at 17:07:21 UTC, Atila Neves wrote:
>> On Thursday, 8 February 2024 at 05:12:06 UTC, Paul Backus 
>> wrote:
>>> By the way, one of the key techniques that makes this work is 
>>> having the allocators wrap each void[] they return in a 
>>> non-copyable struct, so that it can only be deallocated once. 
>>> So you can probably understand why I'm so concerned about 
>>> support for non-copyable types in Phobos v3. :)
>>
>> What specifically would we need support for?
>
> It's not really any specific thing; it's more that Phobos's 
> general attitude towards non-copyable types needs to change.
>
> Currently, there are a huge number of interfaces in Phobos 
> that, in principle, could work with non-copyable types, but 
> just don't, because no one ever thought of it or cared enough. 
> Such interfaces include:
>
> - Large portions of std.range and std.algorithm
> - std.format in its entirety
> - std.typecons.Tuple
> - std.array.Appender
> - etc.
>
> From how widespread it is, it's clear that this is not an issue 
> of specific bugs or design mistakes. It's a systemic problem in 
> the way Phobos's code is written, tested, and reviewed.

I see. This is an instance of a more general problem of "nasty 
types" that do "weird" things such as being uncopyable. Ideally 
we'd have one in Phobos just for testing and feed it to basically 
everything. FeepingCreature mentioned something like to me at 
DConf but I can't find it in github after googling.