Add SumType.typeIndex

[pbackus]

Fixes #56.

[deviator]

request yet another clarification

your code with CopyTypeQualifiers proposed as external solution, but from inside SumType you can return tag directly (with minimal type of enumeration: ubyte in 99% cases)

or I don't see something important in this solution?

[pbackus]

It's theoretically possible for a const(SumType) to have two tag values that correspond to the same (qualified) type. In this case, the CopyTypeQualifiers solution is necessary to ensure that we always return the same index when the (qualified) type is the same.

[deviator]

okey, but why don't return Tag type?

[pbackus]

Mainly because the Tag type is private. If it really matters, you can cast the return value.

[deviator]

It's theoretically possible for a const(SumType) to have two tag values that correspond to the same (qualified) type. In this case, the CopyTypeQualifiers solution is necessary to ensure that we always return the same index when the (qualified) type is the same.

I try to adopt my sbin library and don't understand one moment: if I try serialize sumtype value with const and not const payload I can't pass in value to serialization function, because I lost original type index, right?

simple example:

/+ dub.sdl:
    dependency "sumtype" version="1.1.0"
 +/

import std.stdio;
import sumtype;

alias S1 = SumType!(const(int[]), int[]);

void printConst(in S1 v) { writeln(v.typeIndex); }
void printRef(ref S1 v) { writeln(v.typeIndex); }

void main()
{
    int[] value = [1,2,3];
    auto s = S1(value);
    printConst(s); // 0
    printRef(s); // 1
}

Can you explane how to serialize sumtype value and deserialize after and get the same payload? Serialization function must get const value because it must not change anything in value, deserialization function get ref.

[pbackus]

If you serialize from a mutable SumType, then deserializing to a mutable SumType will always give you the same thing you started with. If you serialize from a const(SumType), then deserializing to a const(SumType) will always get you the same thing you started with.

If you serialize from a const(SumType) and deserialize to a mutable SumType (or vice versa), you may not get the same thing you started with in this particular corner case. So if you're writing a generic library, you should either avoid doing that, or put a compile-time check in your code to detect the corner case—something like static assert(is(NoDuplicates!(staticMap!(ConstOf, S1.Types)) == S1.Types)); should work.

[deviator]

If you serialize from a mutable SumType, then deserializing to a mutable SumType will always give you the same thing you started with. If you serialize from a const(SumType), then deserializing to a const(SumType) will always get you the same thing you started with.

You don't understand, I serialize mutable object, but pass it into serializer with in qualifier and it const only inside serializer function. This mechanics get me different information about one object in different places. I think it will be useful to get same information as is about one object (const ref or not).

Why I have interest with [de]serialization? Because [de]serialization is place where algebraic types are most useful in D, if no need serialize simple data objects and/or they more complicated, then classes can be used (classic OOP). For [de]serialization simple data getting raw information about stored data is very useful. In this case it's tag type (ubyte or some enum for comfortable foreach by it), read-only tag (simple index), type by tag (indexing Types in simple way). This information already in SumType object, but it private. Making it public not make sumtype unsafe or not compatible with -betterC. I don't understand why you don't want make it public. Only because you don't need it? Then why you push sumtype to std if you don't keep in mind different cases of use library by other people? In std must be generic code that can meet the needs the most part of D coders, not only peoples who write std...

[pbackus]

Please calm down. The kind of accusatory language you are using is entirely uncalled for, and you will be blocked from commenting here if you use it again.

The current version of typeIndex is designed to always return the same index for the same value type—that is, it gives consistent results across different objects of the same type. Your proposal is that we should give up this consistency in order to achieve consistent results for the same object across different types.

Either way, there is a tradeoff being made. You have made a reasonable argument that the tradeoff chosen by the current version is the wrong one, and should be changed, so I have created #58 to address this.

[deviator]

Please calm down. The kind of accusatory language you are using is entirely uncalled for, and you will be blocked from commenting here if you use it again.

I didn't mean to sound rude. I'm sorry.

Serialization and deserialization is general case (to json, yml or xml for example). Can you please show example how to serialize sumtype object and deserialize it to original state (for example to and from abstract text representation)? By now I don't see easy (short) way, it requires many non trivial or not universal code (synchronize methods of getting tag, tag type, tag limits, type by tag in serialization and deserialization parts, when it simply hidden by private).

[pbackus]

Issue #58 is fixed in v1.1.1. I've opened a new issue for your example request, #60. Please continue the discussion there if necessary.