Allow the usage of out/ref parameters with 'params' in methods.

[Fabi]

I currently made much use of params object[] and noticed that one big missing thing there is the support of of ref & out parameters. I think it would be a great addition to avoid creating many overloads and delegates for things like pinvokes.

Currently I have a solution for pinvokes (syscalls) that generates a new DynamicMethod + IL that allows me to execute code like
syscall<TRet>(id, params) where you don't need to specify any hardcoded list of arguments etc.

There is no way to use ref/out parameters for things like byte arrays though.

[svick]

I'm not sure I understand what exactly you are suggesting. Do you mean combining multiple ref (or out) parameters into a single object/array? That couldn't easily work, because you can't have an array of refs. Or are you suggesting something else?

As for a way of invoking a method with any arguments, reflection already can use object[] for ref and out parameters, so you might be able to use the same approach in your code.

For example, instead of int.TryParse("42", out var value), you can use reflection like this:

delegate bool TryParse<T>(string s, out T value);

…

TryParse<int> intTryParseDelegate = int.TryParse;
var parameters = new object[] { "42", null };
intTryParseDelegate.Method.Invoke(null, parameters);
Console.WriteLine($"{parameters[1].GetType()}: {parameters[1]}"); // prints "System.Int32: 42"

[Fabi]

Let's say I have a method public static T Call<T>(int id, params object[] params) which basically invokes an instance of DynamicMethod with the given params which has IL code to call dynamically allocated asm code that calls a native function like readprocessmemory. This one requires a byte array as out parameter. The same for similar other methods.
Currently I can't add this wenn using my Call method in the params.

basically it would look like that Call<bool>(someId, hProcess, lpBaseAddress, out byte[] lpBuffer, dwSize, out int lpNumberOfBytesRead);

This should not require any delegate declaration or involve too much reflection. That's why having some kind of support of out parameters inside params object[] would be great.

You can see the DynamicMethod as this and just being called with .Invoke later.

static DynamicMethod GenerateNativeMethod<T>(long asmPointer, params object[] parameters)
            {
                var returnType = typeof(T);
                var parameterTypes = parameters.Select(p => p?.GetType()).ToArray();
                var method = new DynamicMethod(string.Empty, returnType, parameterTypes, returnType.Module);
                var gen = method.GetILGenerator();

                for (var i = 0; i < parameterTypes.Length; i++)
                {
                    switch (i)
                    {
                        case 0:
                            gen.Emit(OpCodes.Ldarg_0);
                            break;
                        case 1:
                            gen.Emit(OpCodes.Ldarg_1);
                            break;
                        case 2:
                            gen.Emit(OpCodes.Ldarg_2);
                            break;
                        case 3:
                            gen.Emit(OpCodes.Ldarg_3);
                            break;
                        default:
                            gen.Emit(OpCodes.Ldarg, i);
                            break;
                    }
                }

                gen.Emit(OpCodes.Ldc_I8, asmPointer);
                gen.Emit(OpCodes.Conv_I);
                gen.EmitCalli(OpCodes.Calli, CallingConvention.StdCall, returnType, parameterTypes);
                gen.Emit(OpCodes.Ret);

                return method;
            }

[HaloFour]

So, to be clear about what you're suggesting, it's not that the object[] itself can't participate with ref/out parameters via reflection or dynamic delegate invocation, the issue is more that the values in the modified array are not propagated back to the variables that the compiler used to populate that array.

So:

// given
void Foo(params int[] args) {
    args[0] = 123;
}

// you can call
int x = 0;
Foo(ref x, 1, 2, 3);

// and that would lower to
int x = 0;
int[] temp = new int[] { x, 1, 2, 3 };
Foo(temp);
x = temp[0];

I used int[] instead of object[]here intentionally. Withobject[]` (or really any reference type) you lose the type safety required to assign the values from the array back into any variables.

[svick]

With object[] (or really any reference type) you lose the type safety required to assign the values from the array back into any variables.

I think that's a pretty important caveat, because that's the motivating case. If that is not going to work (and I think avoiding possible InvalidCastExceptions is a good reason for that), then is this feature even useful?

[Fabi]

I think that's a pretty important caveat, because that's the motivating case. If that is not going to work (and I think avoiding possible InvalidCastExceptions is a good reason for that), then is this feature even useful?
This is the one of the most important parts there too yes^^

[Fabi]

Actually I'm sorry about types like byte[]. They are filled regardless of the usage of ref or out. Means passing that to such a native call method already works. It would just be nice to let it work directly with out instead of declaring a new byte[] before calling.
But yea in general it's about ref & out support here with params object[]

[HaloFour]

Arrays are reference types, when they are passed around any changes to the array are reflected in any code referencing that same instance. You'd only use ref or out with a reference type when you actually want to pass back a reference to a different instance than the one that was originally passed in.

For value types, like primitives, the compiler is assigning a copy of the value to the object[] array prior to calling the method. The value in the array may change but since it is a copy those changes aren't reflected in the original value type. The compiler would need to copy the value from the array back to the original variable.

You can probably see this yourself by passing an object[] directly to your method instead or relying on params. After the method call and the invocation of the dynamic method the values within the array should be different.

[Fabi]

Arrays are reference types, when they are passed around any changes to the array are reflected in any code referencing that same instance. You'd only use ref or out with a reference type when you actually want to pass back a reference to a different instance than the one that was originally passed in.

For value types, like primitives, the compiler is assigning a copy of the value to the object[] array prior to calling the method. The value in the array may change but since it is a copy those changes aren't reflected in the original value type. The compiler would need to copy the value from the array back to the original variable.

You can probably see this yourself by passing an object[] directly to your method instead or relying on params. After the method call and the invocation of the dynamic method the values within the array should be different.

Well this doesn't help with having the syntax sugar of using ref and out with params which would be really great and solve many self made solutions (there are no really nice solutions to this)

[HaloFour]

I don't think there really is a solution here. You're trying to blend statically typed methods with dynamic invocation which is inherently brittle and probably shouldn't be encouraged by the language. The recipient of that object[] can put literally anything in there, and when the caller would attempt to assign that back to any specific variable that would invariably cause a runtime exception and there'd be no indication that this could happen.

I do believe that the appropriate pattern for emitting a dynamic method is to convert it to a typed delegate where you can define the parameters to be whatever you wish, including using ref, out, in or any other modifiers that cannot be applied to params object[] or the generic Func<...> family of delegates.

[Fabi]

I don't think there really is a solution here. You're trying to blend statically typed methods with dynamic invocation which is inherently brittle and probably shouldn't be encouraged by the language. The recipient of that object[] can put literally anything in there, and when the caller would attempt to assign that back to any specific variable that would invariably cause a runtime exception and there'd be no indication that this could happen.

I do believe that the appropriate pattern for emitting a dynamic method is to convert it to a typed delegate where you can define the parameters to be whatever you wish, including using ref, out, in or any other modifiers that cannot be applied to params object[] or the generic Func<...> family of delegates.

The runtime exception doesn't matter in this case. Some thing would be fully up to the developer to make sure that they are correct. This is one.

Your solution would only work on compile time and also would make the reason why I opened it totally useless. It's no option here to declare any typed delegate. The goal is to to not have this work in favor of the risk to let the developer handle the signature that is being called correctly.

[HaloFour]

This feature cannot just be considered for your use case, it must be considered across all use cases. Your scenario is very niche and very advanced and you may be able to justify that a developer making use of your framework should have a minimum level of expertise with the language. But params, ref and out are all incredibly basic features that have been with the language for 20 years and are expected to be used by any and all developers of any skill level. The ease in which this can result in an accidental runtime exception I think makes it too risky to try to paper over a dynamic runtime invocation with what looks like statically typed dispatch.

void M(params object[] args)
{
    args[0] = "foo";
}

M(out int i); <-- this definitely should not result in a runtime exception

[HaloFour]

Actually, I can think of one way in which it could work. The type of the ref/out variable must be the same type as the params array. I don't think that this would work for your use case at all, but at least it keeps it typesafe:

void M1(params int[] args)
{
    args[0] = 123;
}

void M2(params string[] args)
{
    args[0] = "foo";
}

M1(out int i1); // ok
M1(out string s1); // compile time error
M2(out int i2); // compile time error
M2(out string s2); // ok

[Fabi]

Actually, I can think of one way in which it could work. The type of the ref/out variable must be the same type as the params array. I don't think that this would work for your use case at all, but at least it keeps it typesafe:

void M1(params int[] args)
{
    args[0] = 123;
}

void M2(params string[] args)
{
    args[0] = "foo";
}

M1(out int i1); // ok
M1(out string s1); // compile time error
M2(out int i2); // compile time error
M2(out string s2); // ok

Wouldn't the compiler be able to do the same checks when used with params object[] and also keep it typesafe then?