Following the recent 1.0.0 release [1], I have decided to submit sumtype [2] for inclusion in Phobos, D's standard library. The PR can be found here:

https://github.com/dlang/phobos/pull/7702

This thread is for you, the D community, to give your feedback, comments, reviews, and constructive criticism regarding both sumtype itself, and my proposal to include it in D's standard library. Please keep your replies on-topic. If you are unsure what to include in your comments, the Boost reviewer guidelines [3] have some good advice.

THIS IS NOT A VOTING THREAD. IF YOU WISH TO SHOW SUPPORT/OPPOSIION, GIVE THE PR A "THUMBS UP" OR "THUMBS DOWN" ON GITHUB.

[1] https://forum.dlang.org/post/zagxftjoxxzirneavymj@forum.dlang.org
[2] https://code.dlang.org/packages/sumtype
[3] https://www.boost.org/community/reviews.html#Comments

On Sunday, 22 November 2020 at 13:25:37 UTC, Paul Backus wrote:
> Following the recent 1.0.0 release [1], I have decided to submit sumtype [2] for inclusion in Phobos, D's standard library.

How will this impact std.variant?

On Sunday, 22 November 2020 at 16:03:02 UTC, rinfz wrote:
> On Sunday, 22 November 2020 at 13:25:37 UTC, Paul Backus wrote:
>> Following the recent 1.0.0 release [1], I have decided to submit sumtype [2] for inclusion in Phobos, D's standard library.
>
> How will this impact std.variant?

There will be no changes to std.variant, except that the documentation for Algebraic will be changed to recommend SumType as an alternative.

On Sunday, 22 November 2020 at 13:25:37 UTC, Paul Backus wrote:
> Following the recent 1.0.0 release [1], I have decided to submit sumtype [2] for inclusion in Phobos, D's standard library. The PR can be found here:
>
> https://github.com/dlang/phobos/pull/7702

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.

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.

On Sunday, 22 November 2020 at 13:25:37 UTC, Paul Backus wrote:
> Following the recent 1.0.0 release [1], I have decided to submit sumtype [2] for inclusion in Phobos, D's standard library. The PR can be found here:
>
> https://github.com/dlang/phobos/pull/7702
>
> This thread is for you, the D community, to give your feedback, comments, reviews, and constructive criticism regarding both sumtype itself, and my proposal to include it in D's standard library. Please keep your replies on-topic. If you are unsure what to include in your comments, the Boost reviewer guidelines [3] have some good advice.
>
> THIS IS NOT A VOTING THREAD. IF YOU WISH TO SHOW SUPPORT/OPPOSIION, GIVE THE PR A "THUMBS UP" OR "THUMBS DOWN" ON GITHUB.
>
> [1] https://forum.dlang.org/post/zagxftjoxxzirneavymj@forum.dlang.org
> [2] https://code.dlang.org/packages/sumtype
> [3] https://www.boost.org/community/reviews.html#Comments

The "Basic Usage" examples show functions preceded by "pure @safe @nogc nothrow". Is that required? If so, do we want to go down the path of adding that kind of verbosity/complexity to Phobos libraries? That would be a substantial change from what we have now. It would definitely make the language less appealing (particularly with two starting with @ and two not).

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.

On Wednesday, 25 November 2020 at 15:50:47 UTC, bachmeier wrote:
>
> The "Basic Usage" examples show functions preceded by "pure @safe @nogc nothrow". Is that required? If so, do we want to go down the path of adding that kind of verbosity/complexity to Phobos libraries? That would be a substantial change from what we have now. It would definitely make the language less appealing (particularly with two starting with @ and two not).

IMO, attributes like that should remain in the source code (e.g. the `unittest` blocks from which the docs are built), but not shown in the web page, unless the user hovers over the functions. IIRC, we already do that for template contraints.

Additionally, template functions which don't have any attributes, but have corresponding `unittest`s with attributes, should be displayed in the docs as `pure`-enabled `@safe`-enabled or something along those lines. That's somewhat related to the ADA (Argument Dependent Attribute set) proposal that Mathias presented at this DConf [1].

[1]: https://youtu.be/9lOtOtiwXY4?t=946

On Wednesday, 25 November 2020 at 15:50:47 UTC, bachmeier wrote:
>
> The "Basic Usage" examples show functions preceded by "pure @safe @nogc nothrow". Is that required? If so, do we want to go down the path of adding that kind of verbosity/complexity to Phobos libraries? That would be a substantial change from what we have now. It would definitely make the language less appealing (particularly with two starting with @ and two not).

No, the attributes are not required. They're just there to show that SumType *can* be used in @safe/pure/nothrow/@nogc code, if desired. Maybe it's better to leave them off, though, if they're distracting readers from the main topic of the example.

On Wednesday, 25 November 2020 at 16:02:01 UTC, Petar Kirov [ZombineDev] wrote:
>
> 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.

I just don't see any reason for the extra level of nesting. The module name `std.typecons.tuple` doesn't convey any more information than `std.tuple`. Are we saving the name `std.tuple` for something else? Are we planning on having multiple `tuple` modules in Phobos, such that we'll need to distinguish between `std.typecons.tuple` and `std.something_else.tuple`?

We can (and should, of course) use public imports for backward compatibility regardless of what we name the new modules.