December 30, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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*
|
December 30, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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
|
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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
|
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
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. |
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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. |
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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! |
December 31, 2014 Re: compile-time opIndex | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
Copyright © 1999-2021 by the D Language Foundation