On Sunday, 15 March 2015 at 23:13:58 UTC, Charles Cooper wrote:
> And yes, I could use names. But then you are subject to name clashes and using strings instead of types as member identifiers is more prone to error anyways. Ever gotten this wrong before --
> void CRITICAL_TO_GET_THIS_RIGHT(uint cents, uint dollars);
> ....
> alias params_t = Tuple!(uint, "dollars", uint, "cents");
> ....
> params_t params;
> params.dollars = 0;
> params.cents = 99;
> CRITICAL_TO_GET_THIS_RIGHT(params.expand);
> // compilation succeeds, bank fails.

How would GetByType help here? Both members are uint, so you can't distinguish them by type. And if you gave them distinct types, the bad example here wouldn't compile anymore either.

True. If I had to do something involving such an API I would first wrap the API with a type safe one before doing anything else.

void external_api_do_something(uint dollars, uint cents);
/* I think this could somehow be automated with staticMap and ParameterTypeTuple / ParameterIdentifierTuple */
alias dollars_t = Typedef!(uint, uint.init, "dollars");
alias cents_t = Typedef!(uint, uint.init, "cents");

void internal_api_do_something(dollars_t, cents_t);

On Sunday, 15 March 2015 at 23:20:22 UTC, anonymous wrote:
> On Sunday, 15 March 2015 at 23:13:58 UTC, Charles Cooper wrote:
>
> How would GetByType help here? Both members are uint, so you can't distinguish them by type. And if you gave them distinct types, the bad example here wouldn't compile anymore either.

On Sun, 15 Mar 2015 23:17:34 +0000, Charles Cooper wrote:

> Sure. It is also easy to write merge sort. Or std.typetuple.Erase. Or Tuple.opIndex(size_t). But that doesn't mean everybody does it. Some utilities (and I am not saying this is, but it could be) are widely used enough that it makes sense to put them in the standard.

sorry if you feel offended, i never meant that. what i meant is that it's hard in c++, but easy in D when one knows how to do that. i've learned D mostly by reading other people code, and there is nothing wrong in asking questions, quite the contrary.

but the requested solution is not "universal" enough to be included in Phobos (what if i want an index instead of a value? or (index, value) tuple? or just check if it is there? or find either `int` or `double`?). it's easier to write specialized template for required cases than to try to make it generic (and complex) enough. but it's much harder to write that in c++, to the extent that it's easier to include that things in standard.

just stay with us and you will see that D shines in such things (and in many other areas too ;-).

Not offended at all :), in fact it was not even my suggestion that it be included in the standard. I was just knee jerk reacting to the comment that, just because something is simple to do precludes it from getting standardized

On Sunday, 15 March 2015 at 23:28:18 UTC, ketmar wrote:
>
> sorry if you feel offended, i never meant that. what i meant is that it's
> hard in c++, but easy in D when one knows how to do that. i've learned D
> mostly by reading other people code, and there is nothing wrong in asking
> questions, quite the contrary.
>
> but the requested solution is not "universal" enough to be included in
> Phobos (what if i want an index instead of a value? or (index, value)
> tuple? or just check if it is there? or find either `int` or `double`?).
> it's easier to write specialized template for required cases than to try
> to make it generic (and complex) enough. but it's much harder to write
> that in c++, to the extent that it's easier to include that things in
> standard.
>
> just stay with us and you will see that D shines in such things (and in
> many other areas too ;-).

Charles Cooper:

> Yes, I could say
> external_api1_react_to_event(event_t[1], event_t[0])
> .. but that is barbaric. It's a productivity sink because I have to go back to the original definition, align the arguments, and then context switch back to whatever I was working on before.

If you are experiencing those problems it's probably the way D/Phobos to tell you to not use basic tuples for your purpose. Use tuples with named fields (or even structs).
Take also a look at Algebraic in std.variant.

Bye,
bearophile

On Sun, 15 Mar 2015 23:30:48 +0000, Charles Cooper wrote:

> Not offended at all :), in fact it was not even my suggestion that it be included in the standard. I was just knee jerk reacting to the comment that, just because something is simple to do precludes it from getting standardized

ah, i see. but this has disadvantages too: it's hard to remember everything the std has, and people will write simple things again and again just 'cause it is faster than trying to find the corresponding function in standard library. search is not of great help here too (unless search engine can read programmer's mind and understand what he really wants ;-).

and i still can't see when this can be handy. i'm almost sure that there is a better way to do the thing programmer wants to achieve with such code.

http://dlang.org/phobos/std_variant.html#.Algebraic
Thanks! This is fascinating, really a breath of fresh air coming from the C++ way of doing things.

On Sunday, 15 March 2015 at 23:31:59 UTC, bearophile wrote:
> If you are experiencing those problems it's probably the way D/Phobos to tell you to not use basic tuples for your purpose. Use tuples with named fields (or even structs).
> Take also a look at Algebraic in std.variant.
>
> Bye,
> bearophile