[masklinn]

I have to say I’ve no idea what you mean. In function definitions I’d interpret it as type inference (and would disagree) but you specifically talk about function calls, and consider it a small change. Can you describe what you’re thinking of?

[coder543]

I think I understand what they're asking for. Consider a function that takes in a struct as one of the arguments.[0]

Currently, you would have to invoke it like so:

    svc.GetObjectWithContext(ctx, &s3.GetObjectInput{Bucket: bucket, Key: key})

But... why do you have to type "s3.GetObjectInput"? The function is taking in a concrete type (not an interface) for that argument, and there is only one possible type that you can pass in... so I agree with the person above that it should be possible to elide the type like so:

    svc.GetObjectWithContext(ctx, &{Bucket: bucket, Key: key})

Go already supports type elision in some places, such as...

    []someStruct{{Field: value}, {Field: value}}

instead of having to type

    []someStruct{someStruct{Field: value}, someStruct{Field: value}}

which would be equally pointless repetition.

[0]: https://docs.aws.amazon.com/sdk-for-go/api/service/s3/#S3.Ge...

[qaq]

Yep exactly this ^^ thank you for providing great context that I should've added to the comment in the first place!

[morelisp]

I would also love this. The current rules for when you're allowed to elide are nonsensical.

[masklinn]

Ah yes, that does make sense, I would agree. That Rust doesn't have that (in any context that I know of) is one of its annoyances,