Phobos 3 Discussion Notes - 02-01-2024

[Adam Wilson]

On Saturday, 3 February 2024 at 12:53:34 UTC, Paul Backus wrote:
> Obviously we are not going to get all of Phobos to work with 
> BetterC, but significant chunks of it already do, and there's a 
> good deal more that could be considered low-hanging fruit.
>
> 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.

This is the path that we're taking. We want to make Phobos as 
widely usable as possible, but there is a balancing act we have 
to perform. If we restrict the language features we allow 
ourselves to much, there are entire classes of capabilities we 
cannot deliver. BetterC is too much, for example, we wouldn't be 
able to use classes/interfaces or the GC where it's appropriate.

JMD and I were talking about sockets and I think he came up with 
an interesting approach to this problem. He built a low-level API 
that is either BetterC compliant or very close to it, and then 
built a higher level API on top of that. The low-level API is 
painful to use but it allowed him to build the high-level API he 
wanted in a way that made sense. You can use the low-level API if 
you absolutely need that level of performance/control/etc, but 
most projects will find the high-level API to be sufficient for 
their needs.

Perhaps this is a concept that we should investigate for other 
areas of Phobos?