Enhance functionality of RefTuple labels

[jmh530]

It occurs to me that a slices label[] can fit a slice of RefTuples. So for instance, I can fit dates and really anything else. This is a big win for working with dataframes since it would enable you to create a heterogeneous array where the main data is numerical or some kind but has a more sophisticated set of labels.

However, it seems that there are still some limitations in working with these. So for instance the code below struggles with just reading out the values from them. It doesn't apply in the same way to the original zipped values, suggesting that it is when coercing it to be a label[] that causes the issue.

void main() {
    import mir.ndslice.slice;
    import mir.ndslice.allocation: slice;
    import mir.date: Date;
    import mir.functional: RefTuple, refTuple;
    import mir.ndslice.topology: map, zip, unzip;
    import std.stdio: writeln;

    auto dataframe = slice!(double, RefTuple!(Date, string), string)(4, 3);

    auto dataframe_dates = [Date(2019, 1, 24),
                            Date(2019, 2, 2),
                            Date(2019, 2, 4),
                            Date(2019, 2, 5)
    ];
    
    auto dataframe_colors = ["red", "blue", "red", "blue"];
    auto combined = zip(dataframe_dates, dataframe_colors);
    
    // Fill row labels
    dataframe.label[] = combined;

    // Fill column labels
    dataframe.label!1[] = ["income", "outcome", "balance"];

    writeln(combined.unzip!'a');
    //writeln(dataframe.label!0.unzip!'a'); // error
    writeln(dataframe.label!0[1][0]);
    //writeln(dataframe.label!0.map!(a => a[0])); // error
}

[9il]

To be honest, labels haven't been implemented. They are in the draft state. The idea is to replace Series with labeled Slice. I would like them to work but they aren't on my TODO list.

[jmh530]

It would probably be a good idea to have an issue that lists things that need to get done on them to bring them out of a draft state, even if they aren't on your TODO list.

[9il]

#426

[jmh530]

Thanks. This can probably be closed in favor of that one.