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

[atilaneves]

Reverts #7886

[dlang-bot]

Thanks for your pull request and interest in making D better, @atilaneves! 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#7922"

[n8sh]

Approving and marking for immediate merging since the submitter is the one who has to approve all new public symbols and he does not appear to have approved the PR being reverted.

[Geod24]

Approving and marking for immediate merging since the submitter is the one who has to approve all new public symbols and he does not appear to have approved the PR being reverted.

It would have been nice to have an explanation as to why this is being reverted though. Any kind of context you might have right now will not be known to other people 6 months from now.

[atilaneves]

Approving and marking for immediate merging since the submitter is the one who has to approve all new public symbols and he does not appear to have approved the PR being reverted.

It would have been nice to have an explanation as to why this is being reverted though. Any kind of context you might have right now will not be known to other people 6 months from now.

The rationale is that APIs should prevent misuse, and not going through match is IMHO not the way to use a sum type. All cases should be handled, every time.

[pbackus]

The rationale is that APIs should prevent misuse, and not going through match is IMHO not the way to use a sum type. All cases should be handled, every time.

I agree with this, but do not understand how it justifies excluding typeIndex, sincetypeIndex does not allow the user to bypass match or avoid handling all cases. Is some other kind of misuse you believe it would enable?

[atilaneves]

The rationale is that APIs should prevent misuse, and not going through match is IMHO not the way to use a sum type. All cases should be handled, every time.

I agree with this, but do not understand how it justifies excluding typeIndex, sincetypeIndex does not allow the user to bypass match or avoid handling all cases. Is some other kind of misuse you believe it would enable?

Good point. I still don't see why this would be useful though, and after asking in the forum I didn't see any compelling answers.

[pbackus]

Good point. I still don't see why this would be useful though, and after asking in the forum I didn't see any compelling answers.

The main answer given on the forums was serialization. For example, having access to typeIndex makes it easy to serialize

SumType!(int, string)("hello")

to

{ "type": 1, "value": "hello" }

Of course, you could equally well choose a different schema for your serialized data; for example

1. { "type": "string", "value": "hello" }; or even just
2. "hello"

...but these have their own disadvantages. (1) requires you to define a mapping between types and strings, which is non-trivial in the general case, and (2) makes it impossible to distinguish a plain string from a SumType in the serialized data. I wouldn't go so far as to say that the typeIndex approach is the best one, but there are legitimate reasons one might prefer it over the others.