Similar problem is solved in vibe.d REST generator by using fullyQualifiedName and utility function that provides tuple of local imports needed for parameter type.

On Monday, 17 June 2013 at 07:21:58 UTC, Dicebot wrote:
> Similar problem is solved in vibe.d REST generator by using fullyQualifiedName and utility function that provides tuple of local imports needed for parameter type.

Doesn't help you if the types in question are private, Voldemort types, etc.

David

On Monday, 17 June 2013 at 07:42:54 UTC, David Nadlinger wrote:
> Doesn't help you if the types in question are private, Voldemort types, etc.
>
> David

As it should be, shouldn't it? That is the point of private. Any workarounds can be very misleading.

On Monday, 17 June 2013 at 20:37:39 UTC, Dicebot wrote:
> As it should be, shouldn't it? That is the point of private. Any workarounds can be very misleading.

Nah, I don't think so. For example let's assume you have a module A with a private struct MySuperSecretType. Now A wants to write instances of MySuperSecretType to disk, and it would be natural for a serialization library to be in another module B. But calling B.serialize(mySuperSecretInstance) won't work if serialize(T)(T t) tries to somehow access MySuperSecretType from outside instead of simply referring to its template parameter.

Trying to use the string identifier of symbols in mixin codegen is the "misleading workaround" here.

David