Runtime: string.Join as Concat(separator) extension method on IEnumerable<T>

[TKharaishvili]

I find myself reverting string.Join into an extension method in every project I write. Like so:

``` C#
public static string Concat(this IEnumerable values, string separator = "")
=> string.Join(separator, values);

it's considerably more flexible and enjoyable to use especially when chaining together with Linq to objects queries:

``` C#
intList.Where(n => n > 50).OrderBy(n => n).Concat(", ")

as oppose to:

C# string.Join(", ", intList.Where(n => n > 50).OrderBy(n => n))

So if I'm not the only one using this method this way, maybe we can add it to the corefx.

Note:
I named it Concat because there already exists a standard query operator called Join. The name is as much up for discussion as the feature itself.

[Luchianno]

Though it's only two-line code change, that would be great addition!

[JonHanna]

There already exists a standard query operator called Concat too.

string meanwhile has both a Join and a Concat and this is closer to Join than it is to Concat.

[TKharaishvili]

@JonHanna nice point. Is there any other name you can suggest to avoid confusion or do you think it would be better to stick with Join?

[JonHanna]

If there was going to be something like this, then I'd lean toward Join.

[kerry-perret]

@TKharaishvili I'm not sure to follow the rationale behind that need.

Why not then adding a lot of other String extension methods?

How can we know where to put the bar?

I mean I have plenty of silly extension methods, for instance here: https://github.com/ehouarn-perret/EhouarnPerret.CSharp.Utilities/blob/master/EhouarnPerret.CSharp.Utilities.Core/StringExtensions.cs

Of course some (say a vast majority?) of mine are completely irrelevant or just for the sake (or the fun) to have some sort of fluent API.

While I agree that Join / Concat / whatever String extension method could be something convenient and a nice addition. I'm not seing any serious ground to make it "official" (supposedly the extension method you mentioned is based in the System namespace or something similar).

Instead, in your specific case, would not be more relevant to have a syntax that can turn some static methods into extension methods without the burden of adding new class definitions here and there just because you need it to define an extension method?

[TKharaishvili]

@ehouarn-perret This is not a case of my specific needs here, I have a truckload of extensions myself but I don't open issues regarding all of them.

The point here is that this method is general enough to belong in the standard library and is unquestionably more flexible in the extension form. This is by far not something I have come up with either, other languages namely JS and Ruby have this method in a collection.Join form too.

to have a syntax that can turn some static methods into extension methods

As far as this is concerned, introducing new syntax would firstly be a much harder feature to implement as oppose to adding a two-liner in the library, secondly if not done correctly that would potentially pollute the imported symbol namespace in the file and thirdly it's really a subject of a different discussion and a different repository too because it's a language level thing and it belongs in Roslyn not corefx...

[kerry-perret]

@TKharaishvili

Well that's exactly my point, how can you be so sure that this is _unquestionably_ more flexible in the extension form?

On one hand, I agree with you, in the sense that I would also like to have it as part of the standard library.
On the other hand, a lot of other extension methods (plenty of them) are maybe as well highly desirable while requiring few or no modifications.

That's not the first example of extension method that would be great if it was part of the standard library and yes there is no need to open a ticket to every single extension method that would be nice to have.

This is exactly what led me to ask: how generally-speaking the addition of extension methods part of the standard library can be decided upon something else than the sole _feeling_ of, convenience / general adoption / how can it fit in the standard library, etc.?

About a potential new syntax, I fully agree with you. I digressed and I was merely suggesting it, just thinking about other cases where the static methods already exist in the framework and could be better leveraged as extension methods.
[IMHO this would be a complete mess and yes, this is definitely off topic here]

[AlexGhiondea]

@TKharaishvili would you be willing to come up with a formal API proposal? Having explicit use cases here would make it more clear how it is going to be used.

[SunnyWar]

I, too, see the need for this in countless projects.

[TKharaishvili]

@AlexGhiondea can you give me a guide of sorts of how to create the formal API proposal? Maybe a template or an example of how it should look like?

[AlexGhiondea]

Sure!! We have documented the process here and there is an example at the bottom!

Let me know if you have any questions!

[gulshan]

Coming from Kotlin which has joinToString extension method for arrays and iterables, I miss this in .net. Regarding the API proposal, should that has to be in a separate issue/pr? The extension method with both signature and implementation is (almost same as the original poster)-

public static string JoinToString<T>(this IEnumerable<T> source, string separator = ", ")
        => string.Join(separator, source);

I would like to have the new name JoinToString and the ", " as the default separator instead of "", which will be more useful in my opinion. The usage will look like-

System.Console.WriteLine(Enumerable.Range(1, 7).JoinToString());
// prints-
// 1, 2, 3, 4, 5, 6, 7

The other remaining question is, where should this method be placed? I think as this is an extension to IEnumerable, System.Linq.Enumerable will be a good place.

[stephentoub]

Thank you for the suggestion. As the functionality in question already exists and this is just about creating a potentially slightly more desirable syntax, that syntax could be enabled by a simple extension method in any library, we generally don't add such extension methods to the core libraries, and this issues hasn't seen meaningful progress in years, I'm going to close this.