Phobos 3 Discussion Notes - 02-01-2024

[Jonathan M Davis]

On Sunday, February 4, 2024 2:07:44 AM MST Meta via Digitalmars-d wrote:
> On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:
> > Fix std.traits
>
> Can you expand on this a bit more? I've contributed to std.traits
> in the past and would like to help improve it for Phobos v2.

The main thing that it needs IMHO is going through it and making sure that
it's doing the right thing for each trait and that the exact set of traits
that it has is really what we want, since right now, several of them are
doing the wrong thing (e.g. treating enum as if it were its base type with
stuff like isIntegral, isNumeric, etc., which is a source of bugs). The
names also potentially need to be cleaned up, and it just needs to be looked
over in general to make sure that it's really what we want. It's grown
organically over the years, the current situation with D is not the same as
when std.traits was started, and we've learned more since then, so the exact
set of traits that we want to have in there likely should be adjusted now
that we have an opportunity to essentially start from scratch with it.

That being said, as I understand it, what initiated the idea to rework it as
one of Phobos v3's priorities is that Walter doesn't understand traits like
isSomeChar and finds them confusing, though I suspect that that's probably
because he hasn't done much with them, if nothing else, because dmd doesn't
use Phobos, and I would expect that it does a lot less with templated code
than a lot of D code does, though I haven't dug through its code lately.

I also get the impression that some folks just plain don't like what the
module does, but given how D's template constraints work, we fundamentally
need traits like it has even if the exact set that is in there needs work.

There's also likely some debate to be had over std.traits vs __traits. On
the whole, std.traits adds stuff on top of __traits, so plenty of folks use
both, but part of the idea behind std.traits was to make it so that most
code wouldn't need to use __traits. The advantage of that is that the result
is cleaner code (since __traits tends to be pretty ugly), but it also means
more template instantiations. So, I expect that there is going to be some
disagreement on what we should be doing there (though there's no reason why
we can't have traits in std.traits which simply wrap __traits stuff even if
some folks want to use __traits directly as much as possible). But
regardless, there are a number of things that std.traits tests that aren't
in __traits.

In any case, as things stand, I don't think there really is agreement on
what should be done with std.traits, and deciding what exactly needs to
happen with it is one of the things that we're going to need to figure out.

- Jonathan M Davis