RFC: std.sumtype (adding sumtype to Phobos)
Petar
Petar
Wed Nov 25 16:02:01 UTC 2020
On Wednesday, 25 November 2020 at 15:37:42 UTC, Paul Backus wrote:
> On Wednesday, 25 November 2020 at 15:07:38 UTC, SHOO wrote:
>>
>> I think SumType is better to be included in std.typecons.
>> Rather than a new module, I think it is more appropriate to
>> treat it in the same breath as Tuple, Unique, etc.
>
> I considered that as an option. The reasons I decided against
> it were:
>
> 1. std.typecons is one of the largest modules in Phobos, at
> over 9000 lines. One Phobos maintainer I spoke to mentioned
> that they were already considering splitting it up into
> separate modules like std.tuple, std.nullable, std.unique, etc.
> Given all that, adding sumtype's 2500 lines to the pile didn't
> seem like a great idea.
>
> 2. sumtype's unittest suite is compatible with BetterC, but
> std.typecons' is not, so merging the two modules would result
> in worse test coverage (which could lead to regressions in
> sumtype's BetterC compatibility in the future).
>
> 3. sumtype's documentation makes extensive use of
> cross-references, and is much easier to follow when it's on its
> own dedicated page rather than mixed up with a whole bunch of
> unrelated stuff.
FWIW, I'd prefer not to split `std.typecons` into independent
modules like `std.tuple`, `std.nullable`, `std.unique`, etc., but
as as a package containing those modules: `std.typecons.tuple`,
`std.typecons.nullable`, `std.typecons.unique`. So sumtype could
continue to leave in a single module, but under the
`std.typecons` package: `std.typecons.sumtype`. A few years ago
we split std.algorithm like that and this didn't breaking any
existing code as far as I remember, as we used `public import`s
for backward compatibility.
More information about the Digitalmars-d
mailing list