Allow ref/out parameters to come after params parameters

[jamesqo]

Currently, all params parameters must be the last in the parameter list. The rationale for this is because (I assume) otherwise, it would be very hard for the compiler and/or developer to tell which arguments at the callsite corresponded to which parameters.

However, it's also very common/good practice to have ref/out parameters be the last in the parameter list. At the callsite, there is also no chance of confusing these arguments with ones that should be part of the params array, since ref/out arguments have to be explicitly preceded by ref/out even at the callsite. However, the compiler currently prevents you from putting ref/out parameters after params parameters. For example:

// I attempted this while working on a real project.
public static IEnumerable<SyntaxAssignment> RemoveConsecutiveTokens(
    this IEnumerable<SyntaxAssignment> assignments,
    params string[] tokens, // Tokens to remove
    out int index) // Index they were removed at
{
}

Since params parameters and ref/out parameters both have to be last to allow the code to compile/maintain good practice, respectively, it's impossible to have a valid method where you combine them and maintain good practice. You need to workaround it like this:

this IEnumerable<SyntaxAssignment> assignments,
out int index, // BAD: out isn't last parameter
params string[] tokens

or

this IEnumerable<SyntaxAssignment> assignments,
string[] tokens, // UGLY: The caller needs to explicitly use new[] { ... }
out int index

Can we allow ref/out parameters to come after params ones, to make the first code snippet valid? edit: That method could then be called like this:

assignments.RemoveConsecutiveTokens(s0, out int index); // Same as new[] { s0 }, out int index
assignments.RemoveConsecutiveTokens(s0, s1, out int index); // Same as new[] { s0, s1 }, out int index

edit 2: We would not allow omitting the params arguments to mean passing in an empty array. e.g. Although this is valid:

void M(params object[] args) {}
M();

This would not be:

void M(params object[] args, ref int foo) {}
int foo;
M(ref foo); // Error

The reason for this is it's more plausible to forget about/overlook the params argument now that it can be sandwiched in between an arbitrary number of other arguments. And if the compiler doesn't remind us about it, then it could lead to more bugs. Disallowing it is just a minor inconvenience compared to the benefits it brings; users can circumvent it by passing in Array.Empty<T>() or new T[0].

[benaadams]

So would be an expander mid params?

e.g. usage for

RemoveConsecutiveTokens(
    this IEnumerable<SyntaxAssignment> assignments,
    params string[] tokens, // Tokens to remove
    out int index)

assignments.RemoveConsecutiveTokens(s0, s1, s2, s3, out int index);
assignments.RemoveConsecutiveTokens(s0, s1, s2, s3, s4, out int index);
assignments.RemoveConsecutiveTokens(s0, s1, s2, s3, s4, s5, out int index);
assignments.RemoveConsecutiveTokens(s0, s1, s2, s3, s4, s6, s7, out int index);

[jamesqo]

@benaadams Yep, that's how the method would be called. I'll update the description to clarify.

[DavidArno]

Just use a tuple to return both the enumeration and the index. That way you don't then need an out parameter, solving the "which should come last" problem without a language change:

public static (IEnumerable<SyntaxAssignment> cleanedList, int index) RemoveConsecutiveTokens(
    this IEnumerable<SyntaxAssignment> assignments,
    params string[] tokensToRemove)
{
}

[jamesqo]

@DavidArno

Just use a tuple to return both the enumeration and the index.

I don't get how that relates to this issue specifically. Yes, it's possible to use a tuple, but the same can be said of any scenario where out parameters are used.

Suppose there's an imaginary bug in the compiler that prevents someone from being able to use out parameters where they should be able to. Is your advice to them "the compiler team shouldn't have to fix the bug, use tuples instead?"

solving the "which should come last" problem without a language change:

The core issue for me is there does not seem to be a good reason why out/ref parameters are prohibited after params parameters. I opened this issue in the belief that it was an oversight on the part of the compiler team, and that they'd have implemented this beforehand had they considered it. If they have considered this case before, and they have other reasons than the ones mentioned in the description for disallowing this, I'd be happy to reconsider this issue.

[DavidArno]

I don't get how that relates to this issue specifically. Yes, it's possible to use a tuple, but the same can be said of any scenario where out parameters are used.

That was my point: out parameters are a legacy feature. It makes sense to keep support for them to allow interoperability with older code and to avoid breaking existing code. But tuples offer a far cleaner solution and makes sense as the preferred way of returning multiple values from a method.

The compiler currently requires out parameters to come before a params parameter. As the former is now a legacy feature, it makes no sense to me to consider changing that compiler restriction.

[HaloFour]

@DavidArno

That was my point: out parameters are a legacy feature.

You not liking them does not make them a legacy feature. At no point has the team suggested or implied that tuples supplant out/ref parameters.

[jnm2]

Indeed, I would say out var has created a miniature renaissance. Definitely not the awkward pattern it started as.

[benaadams]

But tuples offer a far cleaner solution and makes sense as the preferred way of returning multiple values from a method.

I still haven't seen a satisfying alternative for the if+TryX pattern

Out param

if (int.TryParse("123", out var result)) 
{
    Console.WriteLine(result + 5);
}

Nullable

int? result = int.TryParse("123");
if (result.HasValue) 
{
    Console.WriteLine(result.Value + 5);
}

Value tuple

(bool success, int value) = int.TryParse("123");
if (success) 
{
    Console.WriteLine(value + 5);
}

[jnm2]

Also it's my preferred pattern when using a OneOf type:

OneOf<int, string, Foo> x = ...;

if (x.TryGetItem1(out var number))
{
    // ...
}
else if (x.TryGetItem2(out var text))
{
    // ...
}
// etc

[jnm2]

Since pattern matching (I'm guessing) will never be able to handle that API pattern.

[svick]

@jnm2

Also it's my preferred pattern when using a OneOf type:
Since pattern matching (I'm guessing) will never be able to handle that API pattern.

Why not? This works today in F#:

let x : Choice<int, string, Foo> = Choice1Of3 42

match x with
| Choice1Of3 number -> ()
| Choice2Of3 text -> ()
| _ -> ()

Why do you think pattern matching in C# will not be able to handle this pattern, once recursive patterns are introduced?

[jnm2]

@svick Because I want to match on the names Item1, Item2 etc, not on type. All items may be the same type.

[jnm2]

Because I want to match on the names Item1, Item2 etc

And I'm dreaming I know, but oh the joy if I could have an expanded version of #894 and this was possible:

OneOf<int ThisThing, int ThatThing, int TheOtherThing> x = ...

if (x.TryGetThisThing(out var thisThing))
{
    // ...
}
else if (x.TryGetThatThing(out var thatThing))
{
    // ...
}
// etc.

You might ask why, since I can name the out vars? Because if I could give members derived aliases, I would choose this pattern instead:

switch (x.Which)
{
    case 1:
        // Do something with x.ThisThing
    case 2:
        // Do something with x.ThatThing
    // etc.
}

It's faster and doesn't introduce unneeded locals.

[svick]

@jnm2 I know. Matching on simple type works today in C# (i.e. you have object that can be int, string or Foo). But once you have recursive patterns (which I believe are coming to C#), you should be able to match on e.g. Item1 vs. Item2, assuming those are actually different types (just like they are in F#). I think the code would look something like:

OneOf<int, string, Foo> x = ...;

switch (x)
{
    case Item1(var number):
       // …
    case Item2(var text):
        // …
}

If you mean that OneOf is a single type (and not a base abstract type OneOf with derived types ItemN), then that would indeed be more complicated. But I think it should work with the proposed "user defined operator is", which should also be coming to C#.

[jnm2]

@svick OneOf<T1, T2, T3> is a struct.

assuming those are actually different types

I already have scenarios where this is in use where they are not different types. 😃

[DavidArno]

@benaadams,

Your nullable example can be made far simpler (and as good as using an out var):

if (int.TryParse("123") is int result)
{
    Console.WriteLine(result + 5);
}

Tuples are hampered by the inability to decompose them in an is var expression, so the following doesn't (yet) work:

if (int.TryParse("123") is var (success, value) && success)
{
    Console.WriteLine(value + 5);
}

but it can still be expressed with a pattern:

if (int.TryParse("123") is var tuple && tuple.success)
{
    Console.WriteLine(tuple.value + 5);
}

And using an Option<T> it can also be expressed as a pattern:

if (int.TryParse("123") is Some<int> value)
{
    Console.WriteLine(value + 5); // implicit conversion of Some<int> to int
}

@jnm2

Also it's my preferred pattern when using a OneOf type:

What you want to do is already covered by the Succinc<T> library:

var x = new Union<int, string, Foo>(1);

x.Match()
 .CaseOf<int>().Do(...)
 .CaseOf<string>().Do(...)
 .CaseOf<Foo>().Do(...)
 .Exec();

Though it won't support unions of the same type, eg Union<int, int> as I really can't see a use case for that and so have never supported it. It seems an odd thing to do. Theoretically it's possible using:

var x = new Union<int, int>(1);

x.Match()
 .Case1().Do(...)
 .Case2().Do(...)
 .Exec();

but it wouldn't compile on the first line as you'd end up with an overload conflict on the constructor.

[jnm2]

@DavidArno and, that requires you to allocate lambda closure delegates which are not my favorite thing ever. I also have x.Match(item1 => ..., item2 => ..., etc) which handles the position/name differentiation and is less verbose (and Switch for void returns), but I prefer the if- and switch-statement-compatible APIs.

[DavidArno]

@DavidArno and, that requires you to allocate lambda closure delegates which are not my favorite thing

No closures are involved (unless you want them to be, of course 😁)

[DavidArno]

@benaadams,

Also it's worth pointing out that int.TryParse() is one of those legacy methods I was referring to before.

[HaloFour]

@DavidArno

Also it's worth pointing out that int.TryParse() is one of those legacy methods I was referring to before.

You keep using that word. I do not think it means what you think it means.

[jnm2]

No closures are involved (unless you want them to be, of course 😁)

If I need access to method locals, which is typical, I'd prefer to use a control flow statement rather than a capturing lambda or manually transforming my method state into a class, which are my other options.

Re: int.TryParse is int, as I've complained before, that's not an acceptable way to write a null check.

(Edit: see #788 (comment) and #788 (comment).
@sharwell found the thread I passed over while looking for it. Thanks!)

[jamesqo]

I think we've gotten a little off-topic, everyone... your ideas are great, but tuples/nullables/pattern-matching/etc. are not a replacement for out/ref vars. Even if you think they are, I don't think this is a good issue to debate that.

@VSadov Since you have worked on a lot of ref-related features like ref returns and readonly ref, which makes you an expert at this 😉, I'd like to hear if you have an opinion on this. When params was implemented, did you guys consider this case too, or is it disallowed because you overlooked it?