Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Why doesn't System.String include a constructor capable of taking a IEnumerable<char>?
The expected behavior would be:
var foo = "hello";
var bar = new string(foo.Select(x => x));
Actual behavior:
Cannot convert from 'System.Collections.Generic.IEnumerable<char>' to 'char*'
If there is no obvious reason, I think it could be a nice pull request.
source: String.cs StringNative.cpp
Since there is a constructor overload that takes an array of characters, this should work:
var bar = new string(foo.Select(x => x).ToArray());
Which pretty much eliminates the need for another constructor overload, as the proposed overload would essentially have to do the same thing.
Eric Lippert often discusses why certain features don't make it into the .NET Framework or the C# language. He says:
The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money.
In other words, every feature must have benefits that exceed those costs, and the .NET Team decided in this instance that the extra constructor was not worth it.
Further Reading
Best way to convert IEnumerable to string?
This constructor takes an array of chars as its input. For your use case, you can simply:
var bar = new string(foo.Select(x => x).ToArray());
If you wanted a rationale, you could say that the lazy-loading behavior of the IEnumerable does not give you any added benefit here since you need to read the whole thing anyway to create the string. Whether you convert it to an array before you pass it, as my example does, or pass it an IEnumerable for the constructor to convert, the operations and performance should be almost the same.
List<T> (or any other collection) has a constructor taking an IEnumerable<T>?
List<T> already inherits from the IEnumerable<T> interface, making the constructor implementation trivial.
Jul 6, 2016 at 20:49
String inherits from IEnumerable<char>. I guess making the constructor is trivial too.
IEnumerable<T>; it's IEnumerable<char>. There's a difference, and it's a material one.
Jul 6, 2016 at 20:51
On the one hand we expect convenience, on the other strict OOP principles being applied. If you implement too many convenient overloads, you will soon be implementing a universal type converter in a string class. And then something else. I guess keeping things mean and lean and sticking to the single responsibility principle outweighed the need for more convenience. As others pointed out, there is not really an inconvenience in using ToArray on the argument. It is about putting responsibilities where they belong.
The answer is simple: It wasn't modified when generics were introduced. There is a constructor that takes an array of char, and if it was being written today, it would undoubtedly take an IEnumerable instead, but in order to introduce that after the fact, would require a lot of testing and validation to make sure that there wasn't a regression and that the performance didn't degrade. For something that can be typically be resolved by adding .ToArray(). Sure, a lot more people have to do the .ToArray(), but there's no prior commitment to that.
IEnumerable<char>as a parameter. I suspect the implementation won't be significantly different that presented in his answer.