Question

namespace System.Collections.Generic
  public List<T>    
    public void AddRange(IEnumerable<T> collection)

It seems like it might be an intentional design decision not to return something. I got bitten by this expecting AddRange to be “fluent.”

I was just curious if anyone knew of the design motivations, if there were any, to return nothing?

Answer 1

The other answers are (essentially) correct, but none of them addresses both possibilities for why AddRange might return something.

One reason for doing that would be to create a fluent API, like this:

list.Add(1).Add(2).Add(3);
list.AddRange(aGroupOfNumbers).AddRange(theNextGroupOfNumbers);

To achieve this, the list simply returns itself at the end of the method that mutates the list. As Trisped notes, StringBuilder was doing this before the generic List<T> was introduced.

Another reason to return something, as Felix K. implies, is that the type is immutable. If a list is immutable, it can’t return itself at the end of the method, because it can’t mutate itself; and it can’t return void, again, because it can’t mutate itself. To reflect the change defined by the method contract, the list has to create a new instance that incorporates the change, and then, of course, it has to return that new instance to the caller. People sometimes have a hard time conceiving of that when it comes to collections, but there’s a very well-known type that behaves this way: System.String. As d-b says, nobody expected the list to return anything, because the “classic” imperative programming style uses void methods when mutating data structures.

The designers of the System.Collections.Generic namespace may not have thought of giving their types a fluent API, but if they did, I could see how they might have decided against it. Certainly, the case for a fluent API in StringBuilder is somewhat stronger than the case for a fluent API in List<T>.