Passing variables, preserving UDAs: A Gripe
Timon Gehr via Digitalmars-d
digitalmars-d at puremagic.com
Sun Feb 12 06:01:32 PST 2017
On 08.02.2017 14:09, John Colvin wrote:
> On Wednesday, 8 February 2017 at 07:57:15 UTC, Timon Gehr wrote:
>> On 07.02.2017 22:59, Nick Sabalausky wrote:
>>> Suppose I have some code that operates on a variable's value and its
>>> UDAs. And I want to refactor that code into a reusable function. Sounds
>>> simple enough, right?
>>>
>>> So, consider a basic example:
>>>
>>> ----------------------------
>>> class Foo
>>> {
>>> @("Hello")
>>> string s;
>>> }
>>>
>>> void doStuff(alias var)()
>>> {
>>> var = "abc";
>>>
>>> import std.traits;
>>> assert(hasUDA!(var, "Hello") == true);
>>> }
>>>
>>> void main()
>>> {
>>> @("Hello")
>>> string s;
>>> doStuff!(s);
>>>
>>> auto foo = new Foo();
>>> // Error: need 'this' for 'doStuff' of type 'pure nothrow @nogc
>>> @safe void()'
>>> doStuff!(foo.s);
>>> }
>>> ----------------------------
>>>
>>> Note the error. Naturally, that cannot compile, because you can't
>>> instantiate a template based on the value of a variable at runtime (ie,
>>> based on the value of `foo`).
>>
>> It actually can compile. (It just doesn't.)
>> There is no essential difference between the two cases.
>
> How much work is it likely to be to make this happen in dmd?
The problem is this:
struct S{
int x;
}
void main(){
S s;
alias y=s.x; // silently ignores the 'this' expression, uses S.x
y=4; // error, no this
}
I have brought this up before. The answer was: "Alias declarations are
for symbols, not expressions."
The 'symbol' term should be generalized to include the case of base
symbol together with an access path. I don't think this is very hard to
do, but I don't know how much of DMDs codebase depends on the semantics
being what they are.
> I imagine your frontend can do this already,
Your imagination is correct.
> but that's not a practical solution
> even for the medium term.
The frontends should converge to a common language anyway.
More information about the Digitalmars-d
mailing list