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