Fix Issue 21731 - SumType should provide convenient access to the typ…

[pbackus]

…e index

See pbackus/sumtype#57.

[dlang-bot]

Thanks for your pull request and interest in making D better, @pbackus! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21731	enhancement	SumType should provide convenient access to the type index

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7886"

[Geod24]

Suggested change

	int[] ma = [1, 2, 3];
	int[3] ma = [1, 2, 3];

Wouldn't that be enough to make it work in betterC ?

[pbackus]

In theory, yes. In practice, if I use a stack-allocated static array and construct the SumType with a slice (i.e., MySum(ma[])), the tests will fail even with -preview=dip1000, because the workaround for issue 21229 used in SumType's constructors does not correctly preserve lifetime information about the constructor's argument.

[schveiguy]

Why isn't this just return tag? Doesn't that do the same thing?

[pbackus]

In some rare cases (see unittests) it is possible for the same type to have two different tag values. The current implementation always returns a unique value for a given type, but conversation at pbackus/sumtype#57 has convinced me that this may not be desirable.

[schveiguy]

Hm... so in a case where you have SumType!(int, const int), assigned to a const int, the tag will be 1 with a standard instance, and 0 with a const instance?

I'll point out that returning a value of 1 is still going to be valid in the list of (const int, const int). I would recommend just returning the tag, it's the most expected result, even on a const SumType.

[pbackus]

Yes, I've come the same conclusion myself.

[pbackus]

Buildkite failure appears to be spurious:

fork/exec /usr/bin/buildkite-agent: cannot allocate memory

[schveiguy]

Looks good. Trivial change, looks like some docs were left over from the previous incarnation.

[schveiguy]

This second paragraph should be removed.

[pbackus]

Should it? In the case of something like const(SumType!(A, B))(const(A)()), the type of the value is const(A), which is not present in Types. The first paragraph alone is insufficient to determine the correct behavior in this case (although I'll grant that it is not difficult to guess).

[schveiguy]

Well, you aren't applying the qualifier. You are just returning the tag.

The paragraph suggests something different happens when a qualifier is used.

Perhaps a rewrite is needed. Maybe:

If the SumType is qualified, the index indicates the Type if it were unqualified.

[pbackus]

The specific wording you suggest is incorrect, because the type in Types might already be the qualified version, but I agree that a rewrite is the best solution here.