--- Comment #9 from Manu <> 2012-04-21 05:08:49 PDT ---
(In reply to comment #8)
> (In reply to comment #7)
> > Oooohkay, so now we get to the bottom of it.
> > Right, well I didn't realise that restriction. I just assumed any statically
> > addressable variable was alias-able.
> Any *symbol* is aliasable. It isn't about addresses.

Yeah I see now, but I don't think that's what people intuitively expect.
I've asked for help on various manifestations of this matter on IRC quite a few
times, and so far, zero out of all the people who have helped me seem to
understand that either. They almost all just said something like "yeah it seems
to be a bit finicky, have you tried this, try passing a this kind of thing, try
changing it this way", etc .. suggesting that nobody had any understanding of
what they were trying to do, just fiddling with it until it stopped

Perhaps it would be a good idea to add some informative error message stating
the limitation. The whinge about 'this' certainly lost all meaning to me at
least, I was absolutely convinced 'this' was perfectly calculable at compile
time, and it should work. There was no mention of symbols.

> > So this is a feature request then, not a bug.
> > There's still technically no reason it shouldn't work, it's just not quite 
> > how
> > alias is written?
> > How much trouble would it be to extend 'alias' to include an offset value?
> This is a significant redesign of what alias is.

:/ .. I think though that the mistake I made is what most people expect should
be possible. At least all those that have tried to help me with it so far.

> > Another alternative could be to just invent the appropriate symbol when a
> > reference like this appears. Symbol names follow the d scoping patterns 
> > right?
> > In this case, the symbol would just be my.module.thing.x (or with whatever
> > mangling happens to appear in D symbols).
> Can't you just pass a pointer around?

I don't think I can get a pointer to TLS data at compile time can I? Using the
alias still allows the compiler to generate the correct TLS dereferencing code.

In the cases where I use __gshared I suppose I could, but I'm not sure this
would simplify the code at all. I can imagine it being more difficult to follow
than the mixin version.
Carrying a pointer interferes with typeof(), it also interferes with the
ability to do allMemers, getMember on the instance (as opposed to the type).
getMember only works on aliases(?), so I think I would need to generate mixin
code that uses the strings produced by allMembers to generate expressions that
reference the data I'm interested in anyway.

I'll have a go at it, see how far I get. But I can imagine the result being
very similar to the mixin approach, and probably no simpler for a 3rd person to
follow. A direct alias is certainly be the most clear and concise way to go.

Is it impossible to invent a new symbol when this case is encountered like I
suggest? That could be a simple solution that fits the existing model.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to