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