Championed: "Default values" for out parameters

[jcouv]

@controlflow commented on Thu Apr 02 2015

In methods with out-parameters it is very common to see first statements like:

string DoSomething(string key, out string value, out int id)
{
  value = null;
  id = 0;

  var a = F(key);
  if (a == null) return null;

  var b = G(a);
  if (b == null) return null;

  value = H(b, out id);
  return J(b);
}

While definite assignment rules are definitely good thing to have in C#, statements like this (to satisfy definite assignment rules) looks pretty silly in methods with "early" returns. It may be convenient to allow out parameter "initialization" with some constant default value in-place, using optional parameter syntax:

string DoSomething(string key, out string value = null, out int id = 0)
{
  var a = F(key);
  if (a == null) return null; // ok, 'value' and 'id' are assigned

  var b = G(a);
  if (b == null) return null;

  value = H(b, out id);
  return J(b);
}

---

@ViIvanov commented on Thu Apr 02 2015

Can I call this method like that:

var smth = DoSomething("key");

? Is this side effect?

---

@controlflow commented on Thu Apr 02 2015

@ViIvanov this is declaration-site feature, just to satisfy definite assignment rules. "Default" value has nothing to do with invocations, it's should not be stored in metadata with [DefaultValue] attribute.

---

@svick commented on Thu Apr 02 2015

I don't understand, why does the current syntax look silly?

Also, I think that using the same syntax as optional parameters without actually making the parameters optional would be confusing.

---

@MgSam commented on Thu Apr 02 2015

Agree with @svick. The risk of confusion with this syntax is pretty great, as seen by @ViIvanov's question.

I don't think syntax making it easier to add new methods that use out parameters should really be a priority, as the proposed tuples feature will be much nicer for the caller to interact with and serve the same purpose (returning multiple values).

---

@alrz commented on Thu Dec 22 2016

@gafter I think "caller-receiver parameters" from record spec draft can be applied here for a straightforward Deconstruct implementation.

public void Deconstruct(out string name = this.Name, out int age = this.Age) {}

However, as currently specified, this needs the method to be not static. So you could not use this in an extension Deconstruct method. Fortunately, with "extention everything" it wouldn't be much of an issue.

extension class PersonExtensions : Person
{
  public void Deconstruct(out string name = this.Name, out int age = this.Age) {}
}

This could also be used in record expansion as it is used for With method.

---

@jcouv commented on Sat Oct 21 2017

Moving language design discussion over to csharplang. Thanks

[TonyValenti]

I have often thought that out var should have really been “ref var” in most cases that way I could do things like the following:

Int.tryparse(string , ref var value = 99);
Or:
Var value = 99;
Int.tryparse(string, ref value);

In both cases value only gets assigned if try parse succeeds. Currently because it is an out parameter, any existing value gets blown away.

[alrz]

"declaration expressions" (#973) will enable you to write ref var but only if TryParse was declared with a ref parameter.

[daharper]

I was about to submit this request as well, I would appreciate this feature on out parameters, removes a redundant line of code in many cases.