nullable ref parameters

[cjsio]

This is midpoint between language idea and question for historical leadup into not having nullable byref parameters. Back in vb.net we had exactly this, like:

Public Function AcquireLocationID(ByRef context As HttpContext, Optional ByRef activeProfile As Profile = Nothing) As Integer

Or for my today's instance, in vb would originally look like:

Public Function ProcessDebugKeybinds(ByRef kMod As KeyModifier = Nothing) As KeyModifier

but to achieve the same effect QoL (of omitting a parameter, but still getting the ref value back when the parameter is supplied) requires a function overload parameterless definition, instead of the cleanest and least redundant source solution of just:

void ProcessDebugKeybinds(ref KeyModifier kMod = null) {

Comparison in-vs:

Thanks for your time

[333fred]

Duplicate of #8156.

[cjsio]

Ok but in that thread I don't see any historical explanation on why C# can't or chose not to support this feature despite it being openly available throughout vb.net's lifespan.

[CyrusNajmabadi]

I don't see any historical explanation on why C# can't or chose not to support this feature

the historical explanation is that we have never found it valuable to implement yet in C# versus all the other things we chose to do.

despite it being openly available throughout vb.net's lifespan.

What VB has supposed during its lifetime has no bearing on us or the things we choose to implement ourselves.

[cjsio]

What VB has supposed during its lifetime has no bearing on us or the things we choose to implement ourselves.

Of course not but I find it interesting that vb.net has a single quality of life nicety here that C# unfortunately doesn't, would love to explore viability

[siegfriedpammer]

VB has many features that c# does not have, parameterized properties would be another example. From what I have understood, 100% feature parity is explicitly a non-goal of c# language design. There's always the option to create a VB.NET library that bridges the gap if necessary.

[cjsio]

VB has many features that c# does not have, parameterized properties would be another example. From what I have understood, 100% feature parity is explicitly a non-goal of c# language design. There's always the option to create a VB.NET library that bridges the gap if necessary.

Ok I was just trying to contextualize the value of a nullable ref parameter in a function. I fully understand that 100% parity is not and never has been an objective of C#. That's not at all what I'm getting at.

What I'm getting is that, just like how C#'s quality of life does away with the needless header-file-redefining-method-definitions of C/C++, because they're already defined inside the code itself so why do we need to duplicate just the parameter set / return type / etc, in this same way we currently have to duplicate that into an overload that swallows up any (or each, if you have multiple) ref and/or out parameters.

I love C#'s clarity and concision in practice as a language. Daily workflow is amazing and I thank you all for all that you do. In this same vein, I do wish that this language feature would be considered as it cuts down on superfluous redundancy (not the good kind) in a very real and meaningful way in ref and out style logic paradigms.