The option to conditionally include method arguments

[bud11]

Problem:

In the same way you can use [Conditional("DEBUG")] or similar to exclude a method, while safely removing call sites, I think it'd be helpful if you could exclude particular arguments from a method too.

The obvious use case would be extra method parameters used for debugging. You want these extra method parameters to be constructed and generated and acknowledged, but only in debug builds, or whatever condition you've defined. Otherwise, they don't exist.

The only way I know to do this is with preprocessor if directives right now, but that comes with a lot of boilerplate at the signature and every call site.

Proprosal:

The simplest way I can think of exposing this would be letting you do something like [MethodConditional("DEBUG", 3] - so you have the condition, then the amount of arguments you want to be included from the start. Any further are ignored.
Therefore you would need to keep any conditionally-stripped arguments at the end of the signature, but that seems like a reasonable limitation for the sake of simplicity.

An alternate more flexible idea would be the requirement to supply a string array of the argument names you'd like to include.

Then, any other arguments, both in signature and at call sites, would disappear in builds.

[huoyaoyuan]

How would it work across assemblies? Usually libraries are shipped only in Release configuration, so the callee's behavior can't be affected by callers configuration.

How would the callee deal with the excluded argument? What if it's used in complex expression, or passed as argument of regular method?

[siegfriedpammer]

I second @huoyaoyuan's questions and add

Why are overloads not sufficient to solve this problem?

[huoyaoyuan]

I cant give specific implementation details, Ive never inplemented attributes of my own.

This is not really reaching implementation detail, but a rough picture of how it works.

The reason Im comparing it to Conditional is because that is clearly possible and already exists.

It's way different to conditional method. In fact, the reason for why conditional method is possible describes why conditional argument is not achievable.

You'd just get a build error if the method body contained references to now-missing parts of the method signature, so you'd still have to wrap relevant pieces of the method body in preprocessor ifs.

This sounds like just working as if #if DEBUG additionalParam #endif in method body. Note that this doesn't work well with existing conditional method. The validity of its arguments are compiled in every configuration.

In terms of multiple assemblies. I suppose the build process could include both versions of the method as overloads if the condition had an exposed bool to enable or disable that behavior to maintain external compatibility.

This is way unacceptable. Debug build of libraries are never meant to be shipped.

For anything further than that, its not like [Conditional] or the associated method actually remains in compilation either. I'm not sure why anyone would expect this to be different.

Because C# organizes references by compilation result, not source code.

I've never made a C# proposal before, and I've never created multiple assemblies working together

It's essential to understand the very basic mechanisms before making a successful language proposal. C# is not a source-only language. Everything affects public surface of methods must be considered in compiled-down form.

[bud11]

I mentioned the overload idea because people were bringing up multiple assemblies. Itd make more sense to me to just not have that and the feature not extend outside of one assembly, like how if debug works in the first place. But that's what I assumed you and others were kind of getting at.

The entire point of this idea was to do exactly what if debug does, at the method signature and call site, wrapped around specific undesired arguments automatically - that's it.

[franchyd]

So essentially you want:

...
MyMethod(obj1, arg2, debugArg);
...
public void MyMethod(object obj, object arg, [Conditional("Debug")] object debugArg);

to be syntactic sugar for:

...
#if DEBUG
MyMethod(obj1, arg2, debugArg);
#else
MyMethod(obj1, arg2);
#endif
...
#if DEBUG
public void MyMethod(object obj, object arg, object debugArg)
#else
public void MyMethod(object obj, object arg)
#endif
);

Allowing you to reduce If/elses and prevent refactoring issues when changing variable names.

The translation of the method site is within the realm of possibility
I think the tough part is making the caller site possible. Because it could be called from a different assembly. So the problem you hit is:

1. Project A defines MyMethod
2. Project B references Project A.
3. Project B calls MyMethod with 2 args
4. You compile in Debug so MyMethod has 3 args.
5. Compile Error
   or the other way around.

Solving that would require either:

1. All consuming projects have to define #if elses themselves to call the correct method signature (pretty gross)
2. Redefine the way method signatures work (practically never going to happen)
3. Generate automatic overloads and conditionally restrict them on the caller site. (not robust so unlikely to do this)

[HaloFour]

I think that the only way it could work would be for all of the "conditional" parameters to have a default value. You can't conditionally change the signature of the method already compiled into the referenced assembly, but you could theoretically change how the consumer calls it. That is exactly how ConditionalAttribute works, the method is there but you're instructing callers to elide the method call in certain conditions.

[bud11]

Yeah basically, @franchyd. Slightly different attribute usage/syntax but that is the idea.

I think the tough part is making the caller site possible. Because it could be called from a different assembly. So the problem you hit is:

1. Project A defines MyMethod

2. Project B references Project A.

3. Project B calls MyMethod with 2 args

4. You compile in Debug so MyMethod has 3 args.

5. Compile Error
   or the other way around.

Solving that would require either:

1. All consuming projects have to define #if elses themselves to call the correct method signature (pretty gross)

2. Redefine the way method signatures work (practically never going to happen)

3. Generate automatic overloads and conditionally restrict them on the caller site. (not robust so unlikely to do this)

Im not getting this. I understand the problem fundamentally, which is why I suggested overloads before myself, if it really for some reason needed to be a feature that supported multiple assemblies, even though it opens a bunch of new problems.
But I dont understand why you'd ever even want that, this is conditional compilation; I dont know why you'd expect two instances of conditional compilation.. with different conditions.. to be compatible.
Put another way, for project B, the method would exist with one particular method signature, whatever project A built it as, and thats it. The conditional aspect wouldnt exist at all in project B.