Context:
Go does not allow specifying the name of function parameters in function invocations like in other languages. I don't understand the reasoning behind this.

Proposal:
allow the function parameter name to be specified explicitly in the function invocation.

func Foo (p1 int, p2 int, p3 int) {}
Foo(p1=1, p2=2, p3=3)

The reason for this is not necessarily because I would like to list them in another order in the invocation.
I don't even mid if the compiler forces the parameters to be specified in the same order as the declaration.

The reason is to avoid errors by making it clear what the intended use for the parameter is.

Remember, the function declaration and function invocation are in different places. They are often written by different people in a team or in different teams.
So when I read the invocation Foo(1,2,3), then I need to go look up the function declaration either in the code or in the documentation to understand what these parameters do. When I read Foo(p1=1, p2=2, p3=3), i don't need to look that up, it gives me all I need.

Also, code evolves. When the definition of function changes, and the function parameters are not named in the function invocation, then there is a potential for unintended bugs. You cannot expect the programmer who needs to modify the function declaration to go fix every invocation in every project (some of which he might not even have privilege to). By changing the name of a parameter, the function programmer can indicate a change in the intended use of the parameter.

When everyone consistently names their parameters during invocations, then a change in the function declaration is immediately caught by the compiler and the API users can fix their code accordingly.

I have seen comments on similar proposals like "I don't see a need for this" do not seem to have much experience with the power of this suggested feature.
IN MY OPINION (and I understand that does not necessarily have to be other people's opinion): it makes code readable, unambiguous and prevents unintended errors. A lot of programmers coming from other programming languages probably agree with me. If you don't see a need for it, then don't use it but at least allow people who do feel a need for it to use it. It's the lack of features like this that makes the transition from Python to Go less palatable for me.