Phobos 3 Discussion Notes - 02-01-2024

[Jonathan M Davis]

On Friday, February 2, 2024 11:19:47 AM MST jmh530 via Digitalmars-d wrote:
> On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:
> > Walter and I had a productive conversation yesterday about
> > Phobos 3 and we felt it would be appropriate to share some
> > notes on our discussion.
> >
> > [snip]
>
> When it comes to discussions around functions that allocate to
> the heap, I think there is some benefit in implementing
> lower-level functionality in functions that do not do any
> allocations whatsoever. You can then have higher level API above
> that that controls allocation and is more convenient to use. That
> way users can opt in to whatever they want or write their own
> more convenient API on top of the lower level functions.
>
> May not work for everything, but could be a useful approach.

That's certainly the approach that I think that we should be taking for a
number of things (and to an extent, it's what Phobos already does with some
stuff - just not everywhere). There are plenty of cases where if you really
want something user-friendly, you need to be giving fewer options and just
allocating stuff on the heap, but it often makes perfect sense to build that
on top of much less user-friendly stuff that provides more functionality for
those who really need it.

This is exactly the approach that I've taken with my socket library that I
need to finish one of these days. It provides a low-level API using structs
and @nogc, whereas for higher level socket stuff (e.g. code that needs to
operate on sockets without caring whether they're using SSL/TLS or not),
you're almost certainly going to want classes - and you're definitely going
to want stuff on the heap given the need to do stuff like point to sockets
on other threads to close them.

A much simpler example of this sort of thing that we already have in Phobos
is range-based functions vs array functions - e.g. splitter vs split. The
range-based ones are much more flexible, and they typically don't allocate
(though in some cases might due to closures), but they're also much more
verbose when you actually want to operate on arrays, since then you end up
with calls to array all over the place, and you potentially lose out on
optimization opportunites for those cases where an algorithm can be
implemented more efficiently for an array. So, by having both, you have the
option to avoid the allocations and work with a wider range of types - or
you can use the array-specific version when you don't need those extra
capabilities.

- Jonathan M Davis