I think it would be useful if we could just concat collection with just variable directly without the need to make array for it. It would make code cleaner because sometimes we just want to append some variable into collection
Just add this to Enumerable extension method
```C#
public static IEnumerable
{
return first.Concat(second as IEnumerable
}
var zeroToHundred = Enumerable.Range(0,100);
var zeroToHundredPlusOne = zeroToHundred.Concat(101);
Also, would it be better if we have `Append` and `Prepend` instead?
```C#
public static IEnumerable<TSource> Append<TSource>(this IEnumerable<TSource> items,params TSource[] after)
{
return items.Concat(after);
}
public static IEnumerable<TSource> Prepend<TSource>(this IEnumerable<TSource> items,params TSource[] before)
{
return before.Concat(items);
}
var oneToHundred = Enumerable.Range(1,99);
var zeroToHundredPlusOne = oneToHundred.Prepend(0).Append(101);
While they don't take params the use of Prepend and Append in your example work with Prepend and Append today.
I remember seeing some subtle differences in overloads when you add params (see https://github.com/dotnet/corefx/issues/5552#issuecomment-268395367). We should try to avoid that - maybe it is not relevant here.
@Thaina this is a very tempting API to add in the beginning but after you start thinking about special cases it would be pretty confusing if you had an IEnumerable<object> x and do x.Append(new string[] {2, 3 4}) - should that add 3 elements or one? You might want to store arrays as well as numbers. Unfortunatelly as you see you would need an API with a name something like AppendElement to avoid confusion - note that adding an API means for us that we should rather not remove it after it is being added as it is causing generally frustration and confusion so we need to be really careful when adding new APIs and go through all similar cases. I do agree that AppendElement (or something with better name perhaps) would be useful although this needs to be carefully thought through and that's why we require more formal API design discussions.
I just realize that we could avoid some confusion is to enforce some first element such as
C#
public static IEnumerable<TSource> Append<TSource>(this IEnumerable<TSource> items,TSource item0,TSource item1,params TSource[] after)
{
return items.Append(item0).Append(item1).Concat(after);
}
This way the items.Append(new[] { 0,1,2 }) is invalid
So unless the coder intentionally put items.Append(0,1,new[] { 2,3,4 }) the natural way we would write code is items.Append(0,1,2,3,4)
@Thaina That just pushes the same problem further down the road. It would be surprising when you write items.Append(0, 1, new[] { 2, 3, 4 }) (or items.Append(0, 1, rest)) to an IEnumerable<object> and it adds three elements.
Given there has been little interest and the API seems problematic, I would recommend to close it - @OmarTawfik what do you think?
This is why we have a separate Create and CreateRange, and Add and AddRange, etc.
@karelz I don't mind closing it. We can re-open it if the API proposal was updated to address the concerns mentioned here.
Most helpful comment
@Thaina this is a very tempting API to add in the beginning but after you start thinking about special cases it would be pretty confusing if you had an
IEnumerable<object> xand dox.Append(new string[] {2, 3 4})- should that add 3 elements or one? You might want to store arrays as well as numbers. Unfortunatelly as you see you would need an API with a name something likeAppendElementto avoid confusion - note that adding an API means for us that we should rather not remove it after it is being added as it is causing generally frustration and confusion so we need to be really careful when adding new APIs and go through all similar cases. I do agree thatAppendElement(or something with better name perhaps) would be useful although this needs to be carefully thought through and that's why we require more formal API design discussions.