Allow discard ref and in params by boxing their values directly

[ghost]

If I have this:

void Foo(int x, ref string s)
{
}

I suggest to allow discard any change to the ref parameter by boxing it's value directly like this:
Foo(1, ref "test");

And the same can be done for in params.

This will spare us from defining unnecessary variable that we don't need to reuse after calling the function. VB.NET already allows sending values directly to ref params, and since C# recently allowed discard out params, I think discarding ref and in params will be consistent with that.

[CyrusNajmabadi]

This seems like this would happen so rarely that it really wouldn't benefit from having a language feature to improve thigns here. How often are you encountering this?

[ghost]

@CyrusNajmabadi
In VB6 and VB.NET, I faced this alot, but frankly this may be becuase VB Lakes the out params, so maybe I was discarding out params :)
I can't recall examples now.

[HaloFour]

This used to be a painfully common occurrence when working with COM interop where so often all of the parameters would be ref. If I recall something funky was done with the interop wrappers for at least Office to make those ref parameters act like non-ref parameters, but I don't remember the details or if it applied to other COM libraries. Outside of those situations I don't know how often it would arise.

[CyrusNajmabadi]

I thought C# made it so you could jsut do the com interop without providing those optional ref parameters (or without requiring you to use 'ref'). Is this a real problem anymore?

[CyrusNajmabadi]

I can't recall examples now.

Er... It's hard to justify a language feature when there's no actual real-world examples demonstrating the value :)

[HaloFour]

@CyrusNajmabadi

I thought C# made it so you could jsut do the com interop without providing those optional ref parameters (or without requiring you to use 'ref'). Is this a real problem anymore?

Does that apply to all ref parameters or just optional ref parameters?

It's been a while since I've had to do COM interop with C#, largely against our own VB6 libraries but with Office and third-party COM libraries thrown in for good measure. The Office interop was particularly painful since a lot of those methods accept a bazillion optional parameters but I recall it being obnoxious with the other libraries as well since you needed to separately declare and initialize variables just to satisfy the fact that the parameters were ref. I don't work on that project anymore (it's still very much alive, though) so it's not something I've had to fight with for a while, but the PTSD from it makes me feel that this feature might have some merit, at least where COM interop is involved.

[CyrusNajmabadi]

So, a ton of hat original interop work was done based on feedback from many devs as well as the teams owning those old APIs. They were really happy with the results we got, and since then i can't even recall the last time anyone asked about more improvements here. That makes me take the default position that this isn't actually an issue people are encountering significantly enogh to warrant attention.

Given that we don't even have an exemplar to work with here makes me very skeptical that there is sufficient value.

[YairHalberstadt]

Are there any actual disadvantages to the feature though? I can't think of any.

This particular feature doesn't affect me at all so I wouldn't implement it myself, but with other features which don't appear to have disadvantages, but aren't important enough to be championed, what's the policy if someone from the community offers to implement them?

[CyrusNajmabadi]

what's the policy if someone from the community offers to implement them?

There's no policy at all. If you implement them, there's no harm in that. But without a champion, there's no path forward from that implementation to making it into the language.

Are there any actual disadvantages to the feature though

Sure. It has to be designed, spec'ed, implemented, documents, tested, made to work in all IDE scenarios, etc. etc. etc. There is a high cost to any language feature. As an example, look at the effort necessary to just support $@ as well as @$ strings. That's a language change of one character, but it still has incurred a non-insignificant cost to go do all the work around it.

[jnm2]

And the same can be done for in params.

This is already a feature of in params, IIRC.

[HaloFour]

@CyrusNajmabadi

So, a ton of hat original interop work was done based on feedback from many devs as well as the teams owning those old APIs. They were really happy with the results we got, and since then i can't even recall the last time anyone asked about more improvements here. That makes me take the default position that this isn't actually an issue people are encountering significantly enogh to warrant attention.

You guys scratched the itch where Office is concerned, specifically APIs where the methods contain a metric ton of optional parameters. But it didn't help in the situation of APIs where the parameters are required. Those parameters still must be passed by ref, given that ByRef was the default convention of VB pre.NET and fairly common in the ecosystem. My previous company has a big ecosystem of VB6 COM libraries in production and actively maintained. Most new code is C#, and sometimes older code is migrated when possible, but binary compatibility is a major concern given the sheer amount of custom development done by partners and customers of the product.

To put this into perspective, it's not that uncommon for us to have methods that require upwards of 20 parameters. To call such a method from VB6 is a one-liner. To call such a method from VB.NET is a one-liner. To call such a method from C# requires 21 separate statements.

This may be a relatively rare subset of the overall customers of C#, and supporting COM is probably in the same dustbin as .NET Framework, but it's certainly still painful for developers who have to straddle the worlds of Microsoft Technologies Past.

Furthermore, and this is a bit of a tangent, there is some bizarre stuff in the C# language to enable COM interop that is not a part of the spec and, to my knowledge, can't be exploited by normal C# code. This includes optional ref parameters and direct instantiation of interfaces. In my opinion there should be some discussion about those features and where they belong in the language, especially as .NET Core continues to improve support for COM interop.

[HaloFour]

@CyrusNajmabadi

Just to note, I'm not expecting any movement on an issue like this, particularly if the reason is to improve the situation between VB6 and C#. I think that allowing ref expressions to be passed to ref parameters is harmless but would aid a very small majority of developers. I'm just telling war stories from my personal experience being a very vocal advocate for adopting .NET and particularly C# at my previous company and the pains experienced attempting to do so, even after C# 4.0 was released. I'm glad I don't work there anymore. They still do an awful lot of VB6 development because of the poor migration story.

[CyrusNajmabadi]

But it didn't help in the situation of APIs where the parameters are required. Those parameters still must be passed by ref,

I thought we made it so that you didn't need 'ref' to pass these variables to com interfaces. Since hte vast majority were not actuall in/out params, we just allowed you to pass naked values, and made it work.

[HaloFour]

@CyrusNajmabadi

I thought we made it so that you didn't need 'ref' to pass these variables to com interfaces. Since hte vast majority were not actuall in/out params, we just allowed you to pass naked values, and made it work.

Maybe. I don't have any of the relevant COM interfaces around to check and I don't know what standard COM libraries that ship with Windows 10 might behave in a similar manner.

If that's the case then the language already supports this behavior albeit in a limited way and not as part of the specification. I'd lump it with the other special COM language behaviors I mentioned above as something worth discussion.