Phobos 3 Discussion Notes - 02-01-2024

[Atila Neves]

On Monday, 5 February 2024 at 15:40:11 UTC, Paul Backus wrote:
> On Monday, 5 February 2024 at 14:38:56 UTC, Atila Neves wrote:
>> On Saturday, 3 February 2024 at 12:53:34 UTC, Paul Backus 
>> wrote:
>>> I think the right approach here is to try to make code 
>>> BetterC-compatible when we can, and to at least keep BetterC 
>>> compatibility in mind as a "nice-to-have" goal (but not a 
>>> requirement) when doing API design. For example, if the only 
>>> thing keeping a function from being BetterC-compatible is 
>>> that it uses the GC to allocate memory for an error message, 
>>> it's probably worth a little bit of extra effort to either 
>>> get rid of that GC dependency, or provide a `version 
>>> (D_BetterC)` alternative.
>>
>> I think our goal is to make `-betterC` obsolete. As in: if you 
>> don't use the feature, you don't pay for it, and it's implicit.
>
> This is more of a goal for druntime than Phobos, but yes, 
> agreed.
>
> Even in the 100% pay-as-you-go world, I think we'll still want 
> Phobos APIs to avoid depending on (and paying for) more 
> druntime features than they really need to.

Yeah, that's a good point. For instance: not allocating for no 
reason, and leaving it up to the user instead. If they *want* to 
call `.array` on the result, that's up to them. Preferring "sink" 
`toString` implementations, that kind of thing.