On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven Schveighoffer wrote:
> On 12/18/14 11:54 AM, Dicebot wrote:
>> I wasn't subscribed to druntime changes thus missed this discussion.
>> Will chime in there soon.
>
> Ping, still waiting on this :)
>
> -Steve

*blush*

On 12/30/14 10:51 AM, Dicebot wrote:
> On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven Schveighoffer wrote:
>> On 12/18/14 11:54 AM, Dicebot wrote:
>>> I wasn't subscribed to druntime changes thus missed this discussion.
>>> Will chime in there soon.
>>
>> Ping, still waiting on this :)
>>
>
> *blush*

OK, I see your response, but I'm still curious as to how/whether your DIP would solve it. Any thoughts on the feature brought up in this thread?

-Steve

On Tuesday, 30 December 2014 at 16:25:05 UTC, Steven Schveighoffer wrote:
> On 12/30/14 10:51 AM, Dicebot wrote:
>> On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven Schveighoffer wrote:
>>> On 12/18/14 11:54 AM, Dicebot wrote:
>>>> I wasn't subscribed to druntime changes thus missed this discussion.
>>>> Will chime in there soon.
>>>
>>> Ping, still waiting on this :)
>>>
>>
>> *blush*
>
> OK, I see your response, but I'm still curious as to how/whether your DIP would solve it. Any thoughts on the feature brought up in this thread?
>
> -Steve

In this specific case I actually expected this to work:

struct S
{
    int key, value;

    import std.typetuple;
    alias asTuple = TypeTuple!(this.tupleof);

    alias asTuple this;
}

void main()
{
    S s;
    s[0] = 42;
}

However it does not seem to recognize that `this` pointer is available in such specific invocation. It can be a bug or there may be a legitimate reason preventing it - not entirely sure. Unfortunately I have never completely understood cases when alias is able to preserve context pointer and when it can't.

If it worked though, my proposal would allow more customized access:

struct S
{
    int x;

    template MyTuple()
    {
        alias opIndex(size_t i) = S.x;
    }

    alias MyTuple this; // note it is not MyTuple!()
}

void main()
{
    S s;
    s[100] = 42;
    assert(s[50] == 42);
}

It is not exactly the thing you were originally looking for but I am against any attempt to try adding template argument list flavor to "normal" aggregates - it creates many new corner cases to consider. One example was mentioned in DIP - if `static opIndex` is the thing why can't you do S[0] but only s[0]? It is static after all! More tricky stuff to explain - not worth the feature in my opinion.

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!

artur

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 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.


T

-- 
In theory, there is no difference between theory and practice.

On Wednesday, 31 December 2014 at 21:37:37 UTC, H. S. Teoh via Digitalmars-d wrote:
> Very nice! Now make it work for int* and string*, but indexing the tuple
> 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.

My original point was that it shouldn't be done even if it can be done.

On Wed, Dec 31, 2014 at 09:41:18PM +0000, Dicebot via Digitalmars-d wrote:
> On Wednesday, 31 December 2014 at 21:37:37 UTC, H. S. Teoh via Digitalmars-d wrote:
> >Very nice! Now make it work for int* and string*, but indexing the tuple 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.
> 
> My original point was that it shouldn't be done even if it can be done.

Point. But that means we've gone nowhere with AA .byPair().

If I wanted to stir up controversy, I'd say that the ultimate cause of this issue was the fact that struct fields can't be ref; otherwise it would be a non-problem (make .key and .value ref, and then .tupleof will Just Work(tm)).


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

On Wednesday, 31 December 2014 at 22:05:37 UTC, H. S. Teoh via Digitalmars-d wrote:
> Point. But that means we've gone nowhere with AA .byPair().
>
> If I wanted to stir up controversy, I'd say that the ultimate cause of
> this issue was the fact that struct fields can't be ref; otherwise it
> would be a non-problem (make .key and .value ref, and then .tupleof will
> Just Work(tm)).

struct S(Key, Value)
{
    private:
        Key*   _key;
        Value* _value;

    public:
        ref Key key()   @property { return *this._key; }
        ref Key value() @property { return *this._value; }
}

and no need for tuple weirdness.

On Wed, Dec 31, 2014 at 10:35:18PM +0000, Dicebot via Digitalmars-d wrote:
> On Wednesday, 31 December 2014 at 22:05:37 UTC, H. S. Teoh via Digitalmars-d wrote:
> >Point. But that means we've gone nowhere with AA .byPair().
> >
> >If I wanted to stir up controversy, I'd say that the ultimate cause of this issue was the fact that struct fields can't be ref; otherwise it would be a non-problem (make .key and .value ref, and then .tupleof will Just Work(tm)).
> 
> struct S(Key, Value)
> {
>     private:
>         Key*   _key;
>         Value* _value;
> 
>     public:
>         ref Key key()   @property { return *this._key; }
>         ref Key value() @property { return *this._value; }
> }
> 
> and no need for tuple weirdness.

That's what I have right now. The catch is how to make S behave like a tuple. Or perhaps that's a fool's errand, and we should rename the function to .byKeyValue, and leave .byPair for Phobos where it can just package up .key and .value pairs in std.typecons.Tuple, as people demanded.


T

-- 
IBM = I'll Buy Microsoft!

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.