Add named argument parsing support

[dkorpel]

Start implementing https://www.dlang.org/dips/1030

Does not do the hard part yet, but it's a start. Named (template) arguments are parsed to a NamedArgExp, which result in a "not implemented" error during semantic analysis.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14475"

[maxhaton]

Are the argument pairs really expressions?

[maxhaton]

It might make the semantic analysis easier if (I just though of this now) if a NamedArgExp is actually a call expression with named arguments.

[maxhaton]

Currently this being part of the expression hierarchy sounds like a bad idea

[maxhaton]

The argument matching needs to be done lexically and semantically so having them as expressions has some potential for wacky shit to happen

[dkorpel]

I don't know what you mean with "argument matching needs to be done lexically and semantically".

[dkorpel]

It might make the semantic analysis easier if (I just though of this now) if a NamedArgExp is actually a call expression with named arguments.

A CallExp has an Expressions* arguments, where would I store the names of the named arguments if not in a NamedArgExp?

[maxhaton]

Implementing the semantic analysis for function calls to normal functions is fairly easy, implementing the semantic analysis to anything with an overload (ESPECIALLY a template overload) is absolutely hell on earth because it tries to save references to the arguments all over the place so if you start overwriting them piecemeal as you go through them stuff just randomly breaks.

[maxhaton]

And think about it, you overwrite the array, any error message, AST dump etc., now prints something which is complete gibberish since it's printing what the compiler lowered the arguments into not how the user wrote them down - even worse, this is actually still wrong because the arguments are supposed to be evaluated in lexical order which is now not the order in the AST.

[ghost]

NamedArgExp as proposed here is nice, for example this can be reused for struct literals or I dont know what else in the future (theoritically).

[maxhaton]

Still not an expression

[ghost]

Indeed, you have to follow the DIP.

[Geod24]

@dkorpel : My approach, when I looked at this, was to use a struct with two members. Hence I'm a bit reticent of doing a piecemeal implementation unless we have some guarantee this is the path forward.

[dkorpel]

If it turns out we need a struct instead of a class, we can always change it later.

[maxhaton]

It should be a struct containing an array of pairs of names and expressions.

It cannot be just an array because there's needs to be an opaque migration path away from the rest of the compiler using .args directly

[maxhaton]

I think my branch might be on my GitHub somewhere, I've bumped into all of these problems already. We should start by splitting of the affected logic into callsem.d or something first

[dkorpel]

My approach, when I looked at this, was to use a struct with two members. Hence I'm a bit reticent of doing a piecemeal implementation unless we have some guarantee this is the path forward.

@Geod24 @maxhaton I now have #14575 so you can see where this PR is going towards. Can you re-review based on that?

[RazvanN7]

@dkorpel I think you should just keep the DIP implementation in a single PR but with multiple, independent commits, if possible. Having the implementation scattered over multiple dependent PRs makes it hard to navigate through the changes.

[RazvanN7]

@dkorpel Are you still working on this?

[dkorpel]

Parsing is now implemented without NamedArgExp in: #14776