An idea to resolve usages of auto as return type and alias as parameters

[ryuukk]

For the case of auto as return:

Let's take this example from my project:

    auto view(Includes, Excludes)()
    {
        static if (Includes.args.length == 1 && Excludes.args.length == 0)
        {
            auto storage = assure!(Includes.args[0]);
            return BasicView!(Includes.args[0]).create( storage );
        }
        else
        {

            size_t[Includes.args.length] includes_arr;
            static foreach (i, T; Includes.args)
            {
                assure!(T)();
                includes_arr[i] = type_id!(T);
            }
            size_t[Excludes.args.length] excludes_arr;
            static foreach (i, T; Excludes.args)
            {
                assure!(T)();
                excludes_arr[i] = type_id!(T);
            }
            return MultiView!(Includes.args.length, Excludes.args.length).create(&this, includes_arr, excludes_arr);
        }
    }

Let's pretend i call it this way:

auto myview = registry.view!( Includes!(), Excludes!() )();

How to guess what type it's gonna use?

The function declaration has auto as return type, we could:

• Scan the FunctionDeclaration, and list all the possible returns
• BasicView and MultiView
• Create a new DSymbol and merge all the parts together

Seems like a simple solution yet very effective!

Could do something like i did for the Templates PR and create a FunctionAutoReturnContext, so the type could be build properly in second.d in case it is a template

Now what about alias parameters?

We could scan all call references and do the same thing, build a DSymbol and merge all the parts

I got the idea from: https://github.com/zigtools/ zls/pull/1067 (url split on purpose to avoid useless noise on their PR)

[WebFreak001]

I think this is a good idea, in the typescript compiler it's similarly done with union types, e.g. return type would be BasicView | MultiView, but resolving this later takes enormous work in a solver / resolving algorithm, especially when cases get more complex. I think we should first optimize the current data structures we have, since currently we are starting to get RAM leaks and much longer request times again.