Bug 3081 – unaryFun can't be used to get element out of struct

import std.algorithm; struct Foo { uint num; } void main() { Foo[] foos; auto bar = map!("a.num")(foos); } C:\dmd\windows\bin\..\..\src\phobos\std\functional.d(89): Error: static assert "Bad unary function: a.num for type Foo" This looks like overzealous error checking, as it worked in the old Phobos and now fails a static assert. Probably has to do with the fact that Foo is in a different module than std.functional.unaryFun.

To whom it may concern: would an "I told you so" dance here be appropriate? ;) String mixins are cute, but we need actual macros to be able to do things like this more generally.

(In reply to comment #1) > To whom it may concern: would an "I told you so" dance here be appropriate? ;) > > String mixins are cute, but we need actual macros to be able to do things like > this more generally. For those interested, the cause really _is_ because Foo is defined in a different module. The unaryFun template fails because ElementType.stringof yields "Foo", which isn't visible to std.functional. Even if it could compile the lambda func, the "alias typeof(mixin(testAsExpression))" line still fails because again, Foo is not accessible. That it uses ElementType.stringof also means that it will fail for just about anything other than the builtin types.

Yeah, .stringof shouldn't be used there. But we still can get to the type through the alias. Changing the mixin string to enum testAsExpression = "{ ElementType "~parmName~"; return ("~fun~");}()"; should fix the bug.

(In reply to comment #3) > Yeah, .stringof shouldn't be used there. But we still can get to the type > through the alias. Changing the mixin string to > enum testAsExpression = "{ ElementType "~parmName~"; return ("~fun~");}()"; > should fix the bug. I can confirm that does work. That being said, the amount of acrobatics that had to be performed to make the templates involved not directly refer to the type at hand is somewhat frightening. It reminds me of implementing something by using lambdas several layers deep. This stuff probably has a limit, if not in what it can do, then in the cognitive load on the programmers using it. Too bad macros were scrapped for D2, huh?

Bad enough

Fixed, will come with the next release.

Fixed dmd 2.031