I am writing a library where I would like to be able to store instances of a type of class to an associative array for later usage. Each class stored has to implement a function as part of the required interface. The argument given is always the same type but the return value should be flexible. I solved this with an interface:

interface PathConverter
{
    T toD(T)(const string value) @safe;
}

That interface lets me type the associative array and any other part of the library that needs to use implementers of that interface e.g.

PathConverter[string] converters;

The problem I'm running into is that when compile the library I receive the following error during linking:

error LNK2019: unresolved external symbol _D3app13PathConverter__T3toDTAyaZQjMFNfxAyaZQp referenced in function _D3app14TypedURLRouter__T10setHandlerTPFNfC4vibe4http6server17HTTPServerRequestCQBlQBjQBh18HTTPServerResponseAyaZvZQDmMFEQDaQCy6common10HTTPMethodQBlQEhZ__T9__lambda4TQEvTQDoTASQGt16PathCaptureGroupZQBrMFNfQGiQFaQBlZv

fatal error LNK1120: 1 unresolved externals

Error: linker exited with status 1120

The call is within a delegate to a function that returns a class instance from the associative array. At runtime I fill the associative array. The call looks like this:

tailArgs[i] = getPathConverter("id string").toD!(Parameters!(handler)[i])("string to convert");

Am I running into this error because the linker can't find the instantiation of the template method? How would I give the linker the information it needs? Is there a better way to have an interface with flexible return values?

On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham wrote:

interface PathConverter
{
    T toD(T)(const string value) @safe;
}

https://dlang.org/spec/template.html#limitations

You should get an error from the compiler for trying to do this, instead of just a linker error somewhere else down the line, but either way it's not going to work. You'll have to find another solution.

On Tuesday, 13 September 2022 at 01:46:14 UTC, Paul Backus wrote:

interface PathConverter
{
    T toD(T)(const string value) @safe;
}

Thanks for the spec help Paul. I must've skirted around the compiler somehow. This is a minimal example that triggers the linker error:

interface PathConverter
{
    T toD(T)(string value);
}

class NumberConverter(T) : PathConverter
{
    T toD(T)(string value)
    {
        import std.conv : to;

        return to!T(value);
    }
}

alias IntConverter = NumberConverter!int;

void main()
{
    PathConverter[string] allConverters;
    allConverters["int"] = new IntConverter;
    int converted = allConverters["int"].toD!int("9");
}

Any suggestions for being able to call one function for any instance given but maintain flexible return types?

On Tuesday, 13 September 2022 at 03:00:17 UTC, Kyle Ingraham wrote:

Not sure if it helps, but you can define final methods in an interface, which can call virtual interface methods:

interface PathConverter
{
    string getValue();

    final T toD(T)()
    {
        import std.conv : to;

        return to!T(getValue());
    }
}

Not tested as AFK.

On Tuesday, 13 September 2022 at 08:43:45 UTC, Nick Treleaven wrote:

interface PathConverter
{
    string getValue();

    final T toD(T)()
    {
        import std.conv : to;

        return to!T(getValue());
    }
}

Thanks for the suggestion Nick. I solved this by storing structs as void* in a wrapper struct with information about their module and identifier saved elsewhere. I use that information to setup casts to the appropriate type then call toD. That way I can call the same method for functions that return different types and store disparate structs to the same wrapper struct. The wrapper struct gets used in function signatures.

On Saturday, 1 October 2022 at 21:18:05 UTC, Ali Çehreli wrote:

Thanks for this Ali. I found it useful to see another way to solve this problem. Seems like it would be great to have a Type type that can store a type at compile-time for use at run-time.