On Wed, Dec 31, 2014 at 10:53:37PM +0000, Dicebot via Digitalmars-d wrote:
> On Wednesday, 31 December 2014 at 22:47:05 UTC, H. S. Teoh via Digitalmars-d wrote:
> >That's what I have right now. The catch is how to make S behave like a tuple.
> 
> I don't know why it was considered an important/worthy goal. Trying to provide API based on tuples just hides the fact that there is no real working implementation for them.

I don't know either. The last time round, the byPair PR was shot down because people demanded Tuple support. *shrug* Yet another stalemate.


T

-- 
Acid falls with the rain; with love comes the pain.

On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via Digitalmars-d wrote:
> people demanded Tuple support.

Was it bearophile? :P I can't stop feeling that it is simply not recognized enough how bad D tuples are if such request arises. I'd personally try to avoid those in almost all cases where it is practically feasible.

On 12/31/14 22:35, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Dec 31, 2014 at 10:34:07PM +0100, Artur Skawina via Digitalmars-d wrote:
>> On 12/18/14 16:43, Steven Schveighoffer via Digitalmars-d wrote:
>>> We currently have the ability to do opIndex for simulating an array or other type indexed at runtime.
>>>
>>> But we have no way to simulate the ability of tuple indexing. Such an ability would unleash a huge amount of possibilities, including user-defined tuple types.
>>
>>    struct TupleWannabe(S) {
>>       typeof(S.tupleof) tupleof;
>>
>>       static __memberWannabe() {
>>          string s;
>>          foreach (I, _; typeof(S.tupleof))
>>             s ~= `ref `~S.tupleof[I].stringof~`() @property {
>>                      return tupleof[`~I.stringof~`];
>>                   } `;
>>          return s;
>>       }
>>       mixin(__memberWannabe());
>>
>>       alias tupleof this;
>>    }
>> 
>>    struct S {
>>       int key;
>>       string val;
>>    }
>>
>>    alias ST = TupleWannabe!S;
>>
>>    void main() {
>>       ST s = ST(1, "blah");
>>       s.key = 2;
>>       s.val = "yada";
>>       s[0] = 42;
>>       s[1] = "etc";
>>    }
>>
>> SCNR. Happy new year!
> 
> Very nice! Now make it work for int* and string*, but indexing the tuple

OP only asked for tuple-like indexing for UDTs.

> returns (non-pointer) int and string. This is the original use case that prompted this ER, btw, so if it can't be achieved, then we haven't solved anything.

That is not supported by the _language_. It lacks (1) references and (2) means of controlling object lifetimes. You can easily add a `Ref!` wrapper, but, because of the latter issue, these types of hacks are not a good idea in general.

artur

On 12/31/14 6:05 PM, Dicebot wrote:
> On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via
> Digitalmars-d wrote:
>> people demanded Tuple support.
>
> Was it bearophile? :P I can't stop feeling that it is simply not
> recognized enough how bad D tuples are if such request arises. I'd
> personally try to avoid those in almost all cases where it is
> practically feasible.

Right now, ranges properly work with phobos ONLY if they are tuples (specifically std.typecons.Tuple). The idea is that eventually there will be more support for builtin tuples, and at that point, the requirement will shift to the builtin tuple.

The "fear" is that if you have .key and .value support, and somehow this is impossible to support and also support builtin tuples (I highly doubt this), then we wouldn't be able to use builtin tuples as a return type for aa.byPair.front. Thereby making AA's incompatible with phobos ranges.

IMO, having SOMETHING in AA.byPair is better than nothing. I really am not worried at all about range tuple support, and I think it will be doable when "real tuples" arrive -- support will be additive.

And I'm also with you that if you don't have .key .value support, this isn't worth having.

-Steve