Fix for #163 : Improved import detection for REST interface generators

[mihails-strasuns]

Follow-up for #163
I have no idea how to forge external modules for unit-testing generateModuleImports so tested only on my code. Please review carefully.

I wonder if some more generic type/symbol processing primitives can be designed (and included in phobos) instead of stockpiling similar utility functions.

[s-ludwig]

Looks good as far as I can see. I would only change the alias syntax back to the old alias xyz ident; syntax to keep the code 2.060 compatible until 2.062 is released (it was great to see the new syntax added, though - much cleaner and consistent with the rest of D).

Regarding Phobos inclusion.. maybe something like UserTypeTuple!T with additional support for functions/delegates would be general enough? Sounds like it might be useful for some other things.

[mihails-strasuns]

Sure. Does 2 last DMD version compatibility is general vibe.d policy now?

What should UserTypeTuple do?
I am eager to write something while wisdom provided by Kenji about D type system is still fresh in my mind :) I.e. I have noticed that full and proper implementation of fullyQualifiedName ( which has been merged recently ) almost completely duplicates most code in vibe.http.rest which currently does function signature copying. And I have started thinking about more generic code reuse approach for those tasks. I can't just add phobos pull request for every special case encountered while exploring vibe - I would have been first one to reject them :)

That was a mostly rhetorical question though, I do not think an obvious approach is possible here.

[s-ludwig]

Yeah I wanted to at least always support the previous DMD version to make the transition less painful. People (partially including myself on different machines ;) ) just have too different upgrade policies.

UserTypeTuple would be the same as getSymbols, just handling all kinds of types and returns a tuple with every user defined type that occurs in that type. But I agree that this gets a bit more special than for example BaseTypeTuple or MemberFunctionTuple... so maybe it gets too specific for std.traits.

[s-ludwig]

Thanks for the alias change. I'll merge and test on 2.060.