• Ethan Watson (33/33) Aug 31 2016 https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_cl...
• Ethan Watson (5/9) Aug 31 2016 I also realised that won't work in this case, as getting the
• David Nadlinger (15/19) Aug 31 2016 This analysis is correct, and no, there is no direct way of

Ethan Watson <gooberman gmail.com> writes:

https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/typedescriptor.d

Inside that is some code I have to translate D types to the C++ 
strings that we expect.

I'm in the middle of making a mathematical vector class that I 
will be sticking in Binderoo, but maps functionality to our 
internal SIMD vector class. As such, to keep Binderoo a clean 
interface for anyone to use, it will not contain any  CTypeName 
UDAS for Remedy-specific type info.

The problem comes when I try to alias to the expected type for 
our D code and provide a C++ string override, like so:

//----------------------------------------------------------------------------
module remedy.rl.simdvector;

public import binderoo.math.vector;
public import binderoo.typedescriptor;

alias SIMDVector = binderoo.math.vector.VectorFloat;

enum CTypeNameOverride( T : SIMDVector ) = "r::SIMDVector";

pragma( msg, CTypeString!( SIMDVector ) );
//----------------------------------------------------------------------------

The CTypeString template has no visibility to my 
CTypeNameOverride, and as such that pragma prints out 
"VectorFloat" instead of "r::SIMDVector".

Is there some way to mitigate this without needing to resort to 
mixins everywhere?  This is one of those things in C++ where if I 
specialise a template, any invocation of the template after that 
point will go to the specialised version. But in this case, 
because instantiation happens within the scope of the 
binderoo.typedescriptor module instead of within the scope of the 
module the template is invoking from, it just can't see my new 
CTypeNameOverride specialisation.

I do have other instances inside the Binderoo code where I 
resolve the module names for symbols and mixin an import for that 
to make it all just work, but I'm getting tired of having to do 
that every time I come across this problem.

Ethan Watson <gooberman gmail.com> writes:

On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
 I do have other instances inside the Binderoo code where I 
 resolve the module names for symbols and mixin an import for 
 that to make it all just work, but I'm getting tired of having 
 to do that every time I come across this problem.

I also realised that won't work in this case, as getting the 
module of the SIMDVector alias will infact get the module 
binderoo.math.vector. std.typecons.Typedef might work out just 
fine in this case to do that with though.

David Nadlinger <code klickverbot.at> writes:

On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
 But in this case, because instantiation happens within the 
 scope of the binderoo.typedescriptor module instead of within 
 the scope of the module the template is invoking from, it just 
 can't see my new CTypeNameOverride specialisation.

This analysis is correct, and no, there is no direct way of 
emulating argument-dependent lookup (or the existence of a single 
global scope, for that matter) in D. You have to funnel in the 
information via the template parameter somehow, as you did with 
UDAs.

An alternative solution might be to make the your binderoo 
library use an explicit context, where such overrides can be 
registered manually at the point where both it and the vector 
library in question are in use (i.e. the client library/program). 
One option for this would be explicit context arguments, another 
to wrap the API into one giant template which injects that extra 
information (`alias myBinderoo = binderoo!(overrides, ...); 
myBinderoo.doSomething!foo(bar);`).

  — David