I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:

Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);

The get method takes the field name and the type of the presumed field, and it returns the value of the field in the tuple. If no field by that name and type, return the second argument.

Rquirements:

* Do not throw - allow the second argument to be a throwing delegate

* Do not add overhead if the method is never used

* Figure out a reasonable (but not all too complicated) way to deal with implicit conversions, e.g. if x == "a" in the the code above, should it return 3.14 or convert the int to double?

* Handle qualifiers appropriately


Andrei

On 10/16/16 3:58 PM, Andrei Alexandrescu wrote:
> I was thinking it would be handy if tuples had a way to access a field
> by name at runtime. E.g.:
>
> Tuple!(int, "a", double, "b") t;
> string x = condition ? "a" : "b";
> double v = t.get!string(x, 3.14);

I swear I've seen a pull request merged that adds an accessible "names" AliasSeq with names of fields. That should be a good starting point.

>
> The get method takes the field name and the type of the presumed field,
> and it returns the value of the field in the tuple. If no field by that
> name and type, return the second argument.
>
> Rquirements:
>
> * Do not throw - allow the second argument to be a throwing delegate
>
> * Do not add overhead if the method is never used
>
> * Figure out a reasonable (but not all too complicated) way to deal with
> implicit conversions, e.g. if x == "a" in the the code above, should it
> return 3.14 or convert the int to double?
>
> * Handle qualifiers appropriately
>
>
> Andrei
>

On 10/16/2016 11:07 AM, Dmitry Olshansky wrote:
> On 10/16/16 3:58 PM, Andrei Alexandrescu wrote:
>> I was thinking it would be handy if tuples had a way to access a field
>> by name at runtime. E.g.:
>>
>> Tuple!(int, "a", double, "b") t;
>> string x = condition ? "a" : "b";
>> double v = t.get!string(x, 3.14);
>
> I swear I've seen a pull request merged that adds an accessible "names"
> AliasSeq with names of fields. That should be a good starting point.

Sadly it was closed, not merged. And it was a bit more general allowing getting a field by name from any struct. -- Andrei

On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
> I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:
>
> Tuple!(int, "a", double, "b") t;
> string x = condition ? "a" : "b";
> double v = t.get!string(x, 3.14);

That would mean that tuple then needs to keep the strings around - taking up space. That plus the fact that the following code is equivalent (obviously):

Tuple!(int, "a", double, "b") t;
double v = condition ? t.a : t.b;

Why this addition? What does it enable?

On Sun, 16 Oct 2016 18:51:06 +0000, Sebastiaan Koppe wrote:

> On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
>> I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:
>>
>> Tuple!(int, "a", double, "b") t;
>> string x = condition ? "a" : "b";
>> double v = t.get!string(x, 3.14);
> 
> That would mean that tuple then needs to keep the strings around - taking up space.

It doesn't change Tuple.sizeof.

> That plus the fact that the following code is
> equivalent (obviously):
> 
> Tuple!(int, "a", double, "b") t;
> double v = condition ? t.a : t.b;
> 
> Why this addition? What does it enable?

It's a little bit of runtime reflection, which people sometimes find handy. There's nothing stopping you from writing it manually or with metaprogramming, granted. And if it's just tuples, it doesn't seem like much of an advantage.

On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
> I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:
>
> Tuple!(int, "a", double, "b") t;
> string x = condition ? "a" : "b";
> double v = t.get!string(x, 3.14);
>
> The get method takes the field name and the type of the presumed field, and it returns the value of the field in the tuple. If no field by that name and type, return the second argument.
>
> Rquirements:
>
> * Do not throw - allow the second argument to be a throwing delegate
>
> * Do not add overhead if the method is never used
>
> * Figure out a reasonable (but not all too complicated) way to deal with implicit conversions, e.g. if x == "a" in the the code above, should it return 3.14 or convert the int to double?
>
> * Handle qualifiers appropriately
>
>
> Andrei

Personally, if I wanted this, I'd be using a hash table with Variant objects in it or something.  An argument for keeping tuple features simple is that they really aren't a good tool for doing anything fancy.  If you need a runtime interface, you're probably outgrowing tuples already.  Why not make a struct that contains a hash table?

On Sunday, 16 October 2016 at 20:11:01 UTC, Chris Wright wrote:
> On Sun, 16 Oct 2016 18:51:06 +0000, Sebastiaan Koppe wrote:
>
>> On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
>>> I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:
>>>
>>> Tuple!(int, "a", double, "b") t;
>>> string x = condition ? "a" : "b";
>>> double v = t.get!string(x, 3.14);
>> 
>> That would mean that tuple then needs to keep the strings around - taking up space.
>
> It doesn't change Tuple.sizeof.
>
>> That plus the fact that the following code is
>> equivalent (obviously):
>> 
>> Tuple!(int, "a", double, "b") t;
>> double v = condition ? t.a : t.b;
>> 
>> Why this addition? What does it enable?
>
> It's a little bit of runtime reflection, which people sometimes find handy. There's nothing stopping you from writing it manually or with metaprogramming, granted. And if it's just tuples, it doesn't seem like much of an advantage.

Please, not. We already have great compile time reflection.

On Sunday, 16 October 2016 at 18:51:06 UTC, Sebastiaan Koppe wrote:
> On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
>> I was thinking it would be handy if tuples had a way to access a field by name at runtime. E.g.:
>>
>> Tuple!(int, "a", double, "b") t;
>> string x = condition ? "a" : "b";
>> double v = t.get!string(x, 3.14);
>
> That would mean that tuple then needs to keep the strings around - taking up space. That plus the fact that the following code is equivalent (obviously):
>
> Tuple!(int, "a", double, "b") t;
> double v = condition ? t.a : t.b;
>
> Why this addition? What does it enable?

I don't think this would actually require storing any additional data. It'd be more like:

struct Tuple(Aliases...) {
    auto get(T)(string name) {
        foreach(alias, i; ExtractNames!Aliases) {
            if(alias == name)
                return this[i];
        }
    }
}

Which is the advantage over runtime reflection in this case. It does seem a bit arbitrary to have Tuple include it though. But given that it's a template method (therefore won't be compiled in if not accessed for this particular Tuple type) and requires storing no data in the instance, there's zero overhead if you're not actually using the feature.

On Sunday, 16 October 2016 at 20:11:01 UTC, Chris Wright wrote:
> On Sun, 16 Oct 2016 18:51:06 +0000, Sebastiaan Koppe wrote:
>> That would mean that tuple then needs to keep the strings around - taking up space.
>
> It doesn't change Tuple.sizeof.

Sure, but it still takes up space in the executable. Negligible of course, but for something that doesn't bring anything to the table, not so.

> It's a little bit of runtime reflection, which people sometimes find handy. There's nothing stopping you from writing it manually or with metaprogramming, granted. And if it's just tuples, it doesn't seem like much of an advantage.

Exactly. When you want runtime reflection, would you put it in a tuple?

On Sunday, 16 October 2016 at 16:49:43 UTC, Andrei Alexandrescu wrote:
> Sadly it was closed, not merged. And it was a bit more general allowing getting a field by name from any struct. -- Andrei

The PR in question if anyone is interested: https://github.com/dlang/phobos/pull/4154

I currently lack the time to resurrect this, so anyone is free to take my code if they wish.