Remove "out" word from syntax in C#7

[banjouuid]

When using the new "out" syntax in C#7

queryString.TryGetValue("colorA", out var AColor)

Could in this case the out removed and just leave

queryString.TryGetValue("colorA", var AColor)

as the out should already be implicit there?

[jnm2]

Won't that conflict with the potential declaration syntax in non-out parameters var AColor = Color.Blue?

Because the keyword var can already appear inside the argument list even today (though so far, not at the very beginning of the argument), I think the clarity of the out marker is immediately useful. I would consider it poor practice to leave it out.

[whoisj]

The out keyword isn't just semantics, it's a contract and a descriptive one at that. It's one of the C# features I find myself wishing for in other languages.

[iam3yal]

Even if this is possible what it actually buys? I actually find the former more readable.

[HaloFour]

I don't like the idea of out being implicit. The out/ref keywords actually change the signature of the method call and the flow is more important than the declaration itself. It's four characters (including whitespace), so it's not like we're talking about onerous verbosity.

[jnm2]

You don't want people reading the code to have to sit there and think about whether the parameter is going in or out. Ambiguity is a time sink.

Similarly, the team wishes they had required an iterator keyword on any method that uses yield return like they did with async and await, for exactly this reason. In my view, that is much less important than the out marker.

[DavidArno]

@jnm2,

Similarly, the team wishes they had required an iterator keyword on any method that uses yield return like they did with async and await, for exactly this reason. In my view, that is much less important than the out marker.

Do you have any references for this? yield return and yield break are implementation details of how a method populates an IEnumerable, so requiring the iterator keyword would have been a horrible idea, in my view. Likewise, async is - as I understand it - a necessary "fudge" to prevent await being a breaking change and the feature would have been both easier to understand, and easier on the eye, if they'd not had to do that.

[HaloFour]

@DavidArno

It's come up a couple of times on CodePlex and GitHub Roslyn repos. Here's one such comment by a language team member:

Also, as has been said, I think it'd be ugly for the meaning of the return statement to change based merely on whether there happened to be an await somewhere else in the code. I know that iterators work that way, and it's ugly, and if we could do them over them we would.

It's true that yield is an internal implementation detail but it has such a massive impact on the behavior of the method as a whole that it does make sense to have some keyword to decorate said method. For example, it's quite easy to accidentally refactor an IEnumerable<T>-returning method in such a way that argument validation behavior changes from eager to deferred or vise versa.

[jnm2]

@HaloFour Thanks- saved me from searching dotnet/roslyn for a very similar quote.