Issue/1062

[GrahamTheCoder]

Fixes #1062

@StealthyDeveloper I don't suppose you remember or can see the context of why the code in d34ac82 was added?
It feels like it was trying to avoid a name clash, ambiguous invocation or infinite reference loop, but when I remove that code nothing seems obviously wrong.

I've tested one case here which seemed fine for example

[StealthyDeveloper]

@GrahamTheCoder Hi! Yes that code was fixing this bug: #749. Additionally, if memory serves correctly c# disallows optional ref arguments. This applies to the attribute as well as demonstrated by the two added cases here.
Perhaps emitting a parameterless overload in this case is safest?

Non ref optional parameters should be preserved if they aren't indeed.

[GrahamTheCoder]

Ah yes, thanks. Reading my own message I was a bit vague - you correctly realised it's the removal of the optional attributes I was referring to.
Since the attributes are allowed in C#, we might as well keep them since I believe VB projects will be able to call with the old signature (and the code as it was removed all optional parameters, not just ref ones).

But I see from your example and explanation we'll want converted calls that omit arguments to keep working.
Creating overloads without various parameters would combinatorially explode for several parameters. I think the best thing is probably to inline the default parameter value at each call site.

I was going to create a separate issue for that, but found it was already fixed in #91 and has a test in the repo

This VB seems to convert into something compilable for example.

Let me know if you can see any situation where the output won't compile - apologies if I've misunderstood your point.