Phobos 3 Discussion Notes - 02-01-2024

[Paul Backus]

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.

The attitude that leads to this problem is exemplified by 
Jonathan M. Davis's comments in the "Range Redesign" thread [1], 
but I do not want to single him out. Every single one of us who 
writes and reviews code for Phobos, and allows PRs to be merged 
that fail to handle non-copyable types, is a contributor to the 
problem (including myself!).

If we're going to fix this, whoever's leading the development of 
Phobos V3 (you? Adam Wilson?) needs to make a policy-level 
decision that no PR gets merged unless it either supports 
non-copyable types, or has a good reason not to.

[1]: 
https://forum.dlang.org/post/mailman.618.1705964882.3719.digitalmars-d@puremagic.com