If we want a single IEnumerable<T> representing the concatenation of of two IEnumberable<T>s we can use the LINQ Concat() method.
For Example:
int[] a = new int[] { 1, 2, 3 };
int[] b = new int[] { 4, 5 };
foreach (int i in a.Concat(b))
{
Console.Write(i);
}
of course outputs 12345.
My question is, why is there no overload of Concat() just accepting a single element of type T such that:
int[] a = new int[] { 1, 2, 3 };
foreach (int i in a.Concat(4))
{
Console.Write(i);
}
would compile and produce the output: 1234?
Googling around the issue throws up a couple of SO questions where the accepted answer suggests that the best approach when looking to acheive this is to simply do a.Concat(new int[] {4}). Which is fine(ish) but a little 'unclean' in my opinion because:
Maybe there is a performance hit from declaring a new array (albeit this is presumably going to be negligible pretty much evey time)
It just doesn't look as neat, easy to read and natural as a.Concat(4)
Anyone know why such an overload doesn't exist?
Also, assuming my Googling hasn't let me down - there is no such similar LINQ extension method taking a single element of type T.
(I understand it is trivially easy to roll one's own extension method to produce this effect - but doesnt that just make the ommision even more odd? I suspect there will be a reason for it's ommision but can't imagine what it could be?)
UPDATE:
Acknowledging the couple of votes to close this as opinion based - I should clarify that I am NOT seeking peoples opinions on whether this would be a good addition to LINQ.
More I am seeking to understand the FACTUAL reasons why it is not ALREADY part of LINQ.
In .NET Framework 4.7.1 they added Prepend and Append methods to add one element to the beginning and to the end of enumerable correspondingly.
usage:
var emptySequence = Enumerable.Empty<long>();
var singleElementSequence = emptySequence.Append(256L);
A good reason for inclusion (in one form or another) would be for IEnumerables to be more like functional sequence monads.
But since LINQ did not arrive until .NET 3.0, and is implemented mostly using extension methods, I can imagine that they omitted extension methods working on a single element of T. Still this is pure speculation on my part.
They did however include generator functions, that are not extension methods. Specifically the following:
Enumerable.Empty
Enumerable.Repeat
Enumerable.Range
You could use these instead of homebrew extension methods. The two use cases you mentioned, can be solved as:
int[] a = new int[] { 1, 2, 3 };
var myPrependedEnumerable = Enumerable.Repeat(0, 1).Concat(a);
var myAppendedEnumerable = a.Concat(Enumerable.Repeat(4, 1));
It might have been nice if an additional overload was included as syntactical sugar.
Enumerable.FromElement(x); // or a better name (see below).
The absence of an explicit Unit function is curious and interesting
In the interesting MoreLINQ series of blog posts by Bart De Smet, illustrated using the System.Linq.EnumerableEx, the post More LINQ with System.Interactive – Sequences under construction specifically deals with this question, using the following appropriately named method for constructing a single element IEnumerable.
public static IEnumerable<TSource> Return<TSource>(TSource value);
This is nothing but the return function (sometimes referred to as unit) used on a monad.
Also interesting is the blog series by Eric Lippert on monads, which features the following quote in part eight:
IEnumerable<int> sequence = Enumerable.Repeat<int>(123, 1);
And frankly, that last one is a bit dodgy. I wish there was a static method on Enumerable specifically for making a one-element sequence.
Furthermore, the F# language provides the seq type:
Sequences are represented by the seq<'T> type, which is an alias for IEnumerable. Therefore, any .NET Framework type that implements System.IEnumerable can be used as a sequence.
It provides an explicit unit function as Seq.singleton.
Concluding
While none of this provides us with facts that shed light on the reasons why these sequence constructs are not explicitly present in c#, until someone with knowledge of the design decision process shares that information, it does highlight it would be worth knowing more about.
First - your Googling is fine - there is no such method. I like the idea though. It's a use case that if you run in to, having it would be great.
I suspect it wasn't included with the LINQ API because the designers didn't see a common enough need for it. That's just my conjecture though.
You're right to say that creating an array with just one element isn't all that intuitive. You can get the feel and performance you're going for with this:
public static class EnumerableExtensions {
public static IEnumerable<T> Concat<T>(this IEnumerable<T> source, T element) {
foreach (var e in source) {
yield return e;
}
yield return element;
}
public static IEnumerable<T> Concat<T>(this T source, IEnumerable<T> element) {
yield return source;
foreach (var e in element) {
yield return e;
}
}
}
class Program
{
static void Main()
{
List<int> ints = new List<int> {1, 2, 3};
var startingInt = 0;
foreach (var i in startingInt.Concat(ints).Concat(4)) {
Console.WriteLine(i);
}
}
}
Output:
0
1
2
3
4
Lazy evaluation
Implemented similarly to the built-in LINQ methods (they actually return an internal iterator, instead of directly yielding)
Argument checking wouldn't hurt it
Philosophical questions, I like that.
At first, you can create easily that behaviour with an extension method
public static IEnumerable<TSource> Concat(this IEnumerable<TSource> source, TSource element)
{
return source.Concat(new[]{element});
}
I think the central question is that IEnumerable is an immutable interface and it is not meant to be modified on the fly.
This could (I use could because I do not work in Microsoft so I may be completely wrong) be the reason while the modify part of IEnumerable is not so well developed (in the meaning that you're missing some handy methods).
If you have to modify that collection, consider to use a List or another interface.
Related
I'm writing a very high amount of computed code that need a huge amount of linq stuff, so basically, a method do some stuff, pass to another method do a lot of other stuff using linq. and this is happening like 10k times.
to minimize the effort I created some extensions method that do the repetitive tasks. you can imagine something along this but more complicated
public static IEnumerable<int> IsBiggerThan2(this IEnumerable<int> input){
return input.Where(x=> x>2);
}
public static IEnumerable<int> IsMod2(this IEnumerable<int> input){
return input.Where(x=> x%2==0);
}
public static IEnumerable<int> IsMod3(this IEnumerable<int> input){
return input.Where(x=> x%3==0);
}
my problem is when I use linq, the output is IEnumerable, this could cause to multiple execution, I also don't want to spam .ToList() at end of everyline.
var firstCalculation = someInput.select(x=> x+1);
var biggerAndMod2 = firstCalculation.IsbiggerThan2().IsMod2();
var biggerAndMod2And3 = firstCalculation.IsbiggerThan2().IsMod2().IsMod3();
var biggerAndMod2Plus1= biggerAndMod2.select(x=> x+1).IsBiggerThan2();
// and go on
after many lines it's becoming quite daunting and I wonder why there is no interface that share some characteristic between List and Enumerable.
I can pass IList<int> to IEnumerable<int> but not the vice versa and I need to cast it to list, I am looking for a workaround that I can accept linq result as my Input without needing to cast it to List
public static IEnumerable<int> IsMod3(this ISomething<int> input){
return input.Where(x=> x%3);
}
I tried ICollection, IReadonlyList, IList but no luck, all need to cast to List
Update 1:
in describing the problem I made it over simplified, in those extension methods there are similar cases as what I showed with multiple use of the input arguments. in this way either I need to call .ToList on every input variable or before use of every extensions
The experimental Memoize method from MoreLinq may be what you want.
Regarding LINQ query syntax...
var foo = new List<int> { 1, 2 };
var boo = from n in foo
where n > 1
select n;
...I always thought this syntax was limited to operating on IEnumerable. Or at least until I learned about IQueryable. And perhaps IObservable as well. But I recently noticed a suggestion that query syntax is based on duck typing. That story didn't look terribly convincing, until I found a site that is dedicated to LINQ to Tasks. LINQ to Tasks looks like it is wholly dependent on duck typing with query syntax!
Ok, what is going on here? Is query syntax using duck typing or not? When I give it a try myself, sure enough this works and appears to prove it's all about duck typing, and not IEnumerable:
public class Joker<T>
{
public T Item;
public Joker(T item)
{
Item = item;
}
}
public static class JokerHelp
{
public static T2 Select<T,T2>(this Joker<T> joke, Func<T,T2> call)
{
return call(joke.Item);
}
}
var oof = new Joker<int>(5);
int foo = from a in oof
select a;
If duck typing is how query syntax works, as is evidently the case, where might be official (MSDN) documentation about this? Or any reasonable documentation?
There are a few features in C# that the compiler does structural type matching rather than nominal type matching. Examples include the foreach loop, query comprehension syntax (the select, where, etc), and await/async. For all of these features, the compiler is actually just looking for methods with certain names, not specific interfaces or classes.
The reason these features are not tied to specific interfaces is to decouple the language from the .NET framework implementation as much as possible. I suppose this would be considered a form of duck typing.
Eric Lippert explains the feature and reasoning much more thoroughly here.
I have noticed that the MSDN documentation is often wrong or incomplete about these features.
What you're missing is that List<T> implements IEnumerable<T>. Thus, "I always thought this syntax was limited to operating on IEnumerable" is technically true, though in a limited fashion. IQueryable implements IEnumerable as well, along with IList and arrays. Thus, you can perform linq queries against anything that implements IEnumerable.
Since Joker<> doesn't implement IEnumerable<>, your query attempt will fail. The Select<>(), Where<>(), etc. extension methods are built around IEnumerable<>. So, if you want to select from oof, you just need to update your definition of Joker<>
public class Joker<T> : IEnumerable<T>
{
// (actually implement IEnumerable<T> functionality
}
(Edit: Answer did make some sense in the context of the originally-formatted question. Edited question makes my response obsolete)
I thought it would be nice to do something like this (with the lambda doing a yield return):
public IList<T> Find<T>(Expression<Func<T, bool>> expression) where T : class, new()
{
IList<T> list = GetList<T>();
var fun = expression.Compile();
var items = () => {
foreach (var item in list)
if (fun.Invoke(item))
yield return item; // This is not allowed by C#
}
return items.ToList();
}
However, I found out that I can't use yield in anonymous method. I'm wondering why. The yield docs just say it is not allowed.
Since it wasn't allowed I just created List and added the items to it.
Eric Lippert recently wrote a series of blog posts about why yield is not allowed in some cases.
Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
EDIT2:
Part 7 (this one was posted later and specifically addresses this question)
You will probably find the answer there...
EDIT1: this is explained in the comments of Part 5, in Eric's answer to Abhijeet Patel's comment:
Q :
Eric,
Can you also provide some insight into
why "yields" are not allowed inside an
anonymous method or lambda expression
A :
Good question. I would love to have
anonymous iterator blocks. It would be
totally awesome to be able to build
yourself a little sequence generator
in-place that closed over local
variables. The reason why not is
straightforward: the benefits don't
outweigh the costs. The awesomeness of
making sequence generators in-place is
actually pretty small in the grand
scheme of things and nominal methods
do the job well enough in most
scenarios. So the benefits are not
that compelling.
The costs are large. Iterator
rewriting is the most complicated
transformation in the compiler, and
anonymous method rewriting is the
second most complicated. Anonymous
methods can be inside other anonymous
methods, and anonymous methods can be
inside iterator blocks. Therefore,
what we do is first we rewrite all
anonymous methods so that they become
methods of a closure class. This is
the second-last thing the compiler
does before emitting IL for a method.
Once that step is done, the iterator
rewriter can assume that there are no
anonymous methods in the iterator
block; they've all be rewritten
already. Therefore the iterator
rewriter can just concentrate on
rewriting the iterator, without
worrying that there might be an
unrealized anonymous method in there.
Also, iterator blocks never "nest",
unlike anonymous methods. The iterator
rewriter can assume that all iterator
blocks are "top level".
If anonymous methods are allowed to
contain iterator blocks, then both
those assumptions go out the window.
You can have an iterator block that
contains an anonymous method that
contains an anonymous method that
contains an iterator block that
contains an anonymous method, and...
yuck. Now we have to write a rewriting
pass that can handle nested iterator
blocks and nested anonymous methods at
the same time, merging our two most
complicated algorithms into one far
more complicated algorithm. It would
be really hard to design, implement,
and test. We are smart enough to do
so, I'm sure. We've got a smart team
here. But we don't want to take on
that large burden for a "nice to have
but not necessary" feature. -- Eric
Eric Lippert has written an excellent series of articles on the limitations (and design decisions influencing those choices) on iterator blocks
In particular iterator blocks are implemented by some sophisticated compiler code transformations. These transformations would impact with the transformations which happen inside anonymous functions or lambdas such that in certain circumstances they would both try to 'convert' the code into some other construct which was incompatible with the other.
As a result they are forbidden from interaction.
How iterator blocks work under the hood is dealt with well here.
As a simple example of an incompatibility:
public IList<T> GreaterThan<T>(T t)
{
IList<T> list = GetList<T>();
var items = () => {
foreach (var item in list)
if (fun.Invoke(item))
yield return item; // This is not allowed by C#
}
return items.ToList();
}
The compiler is simultaneously wanting to convert this to something like:
// inner class
private class Magic
{
private T t;
private IList<T> list;
private Magic(List<T> list, T t) { this.list = list; this.t = t;}
public IEnumerable<T> DoIt()
{
var items = () => {
foreach (var item in list)
if (fun.Invoke(item))
yield return item;
}
}
}
public IList<T> GreaterThan<T>(T t)
{
var magic = new Magic(GetList<T>(), t)
var items = magic.DoIt();
return items.ToList();
}
and at the same time the iterator aspect is trying to do it's work to make a little state machine. Certain simple examples might work with a fair amount of sanity checking (first dealing with the (possibly arbitrarily) nested closures) then seeing if the very bottom level resulting classes could be transformed into iterator state machines.
However this would be
Quite a lot of work.
Couldn't possibly work in all cases without at the very least the iterator block aspect being able to prevent the closure aspect from applying certain transformations for efficiency (like promoting local variables to instance variables rather than a fully fledged closure class).
If there was even a slight chance of overlap where it was impossible or sufficiently hard to not be implemented then the number of support issues resulting would likely be high since the subtle breaking change would be lost on many users.
It can be very easily worked around.
In your example like so:
public IList<T> Find<T>(Expression<Func<T, bool>> expression)
where T : class, new()
{
return FindInner(expression).ToList();
}
private IEnumerable<T> FindInner<T>(Expression<Func<T, bool>> expression)
where T : class, new()
{
IList<T> list = GetList<T>();
var fun = expression.Compile();
foreach (var item in list)
if (fun.Invoke(item))
yield return item;
}
Unfortunately I don't know why they didn't allow this, since of course it's entirely possible to do envision how this would work.
However, anonymous methods are already a piece of "compiler magic" in the sense that the method will be extracted either to a method in the existing class, or even to a whole new class, depending on whether it deals with local variables or not.
Additionally, iterator methods using yield is also implemented using compiler magic.
My guess is that one of these two makes the code un-identifiable to the other piece of magic, and that it was decided to not spend time on making this work for the current versions of the C# compiler. Of course, it might not be a concious choice at all, and that it just doesn't work because nobody thought to implement it.
For a 100% accurate question I would suggest you use the Microsoft Connect site and report a question, I'm sure you'll get something usable in return.
I would do this:
IList<T> list = GetList<T>();
var fun = expression.Compile();
return list.Where(item => fun.Invoke(item)).ToList();
Of course you need the System.Core.dll referenced from .NET 3.5 for the Linq method. And include:
using System.Linq;
Cheers,
Sly
Maybe its just a syntax limitation. In Visual Basic .NET, which is very similar to C#, it is perfectly possible while awkward to write
Sub Main()
Console.Write("x: ")
Dim x = CInt(Console.ReadLine())
For Each elem In Iterator Function()
Dim i = x
Do
Yield i
i += 1
x -= 1
Loop Until i = x + 20
End Function() ' here
Console.WriteLine($"{elem} to {x}")
Next
Console.ReadKey()
End Sub
Also note the parentheses ' here; the lambda function Iterator Function...End Function returns an IEnumerable(Of Integer) but is not such an object by itself. It must be called to get that object, and that’s what the () after End Function does.
The converted code by [1] raises errors in C# 7.3 (CS0149):
static void Main()
{
Console.Write("x: ");
var x = System.Convert.ToInt32(Console.ReadLine());
// ERROR: CS0149 - Method name expected
foreach (var elem in () =>
{
var i = x;
do
{
yield return i;
i += 1;
x -= 1;
}
while (i != x + 20);
}())
Console.WriteLine($"{elem} to {x}");
Console.ReadKey();
}
I strongly disagree to the reason given in the other answers that it's difficult for the compiler to handle. The Iterator Function() you see in the VB.NET example is specifically created for lambda iterators.
In VB, there is the Iterator keyword; it has no C# counterpart. IMHO, there is no real reason this is not a feature of C#.
So if you really, really want anonymous iterator functions, currently use Visual Basic or (I haven't checked it) F#, as stated in a comment of Part #7 in #Thomas Levesque's answer (do Ctrl+F for F#).
Does LINQ have a sequence operator, which allows to perform some action on every element without projecting it to a new sequence?
This might see a bit awkward, but just for me to know :)
Example:
IEnumerable<IDisposable> x;
x.PERFORM_ACTION_ON_EVERY_ELEMENT(m => m.Dispose());
Obviously, this could be done using something like:
foreach (var element in x) x.Dispose();
But if something actually exists, that would be nice.
No, it doesn't exist. Specifically for the reason you mention: It seems awkward having a single operator that behaves completely different than all the others.
Eric Lippert, one of the C# Compiler developers has an article about this.
But we can go a bit deeper here. I am philosophically opposed to providing such a method, for two reasons.
The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.)
It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.
You can use this method:
public static class Extension
{
public static IEnumerable<T> ForEach<T>(this IEnumerable<T> source, Action<T> action)
{
foreach (var t in source)
{
action(t);
}
return source;
}
}
It returns the source so you can pass it along to another extension method as needed. Or if you want to be void, you can change the method a little bit.
The morelinq project has a ForEach operator. LINQ itself doesn't, as LINQ is all about functional programming, and ForEach has side effects.
Here is a similar dicussion on this Run a method on all objects within a collection
Why cant I use an IEnumerable with params? Will this ever be fixed? I really wish they would rewrite the old libraries to use generics...
Why cant I use an IEnumerable with params?
The question presupposes that the design team must provide a reason to not add a feature to the language. This presupposition is false.
Rather, in order for a feature to be used by you it needs to be thought of, designed, specified, implemented, tested, documented and shipped. All of these have large costs.
The "params enumerable" feature has been thought of and designed. It has never been specified, implemented, tested, documented or shipped.
Therefore, you cannot use the feature.
UPDATE: As of this writing -- early 2015 -- has now been specified, but implementation, testing, documentation and shipping were cut for C# 6.0 in the latter part of 2014. See Lucian's announcement here: http://roslyn.codeplex.com/discussions/568820.
Since it has still not been implemented, tested, documented and shipped, there is still no such feature. Hopefully this will make it into a hypothetical future version of C#.
UPDATE: I should clarify what I mean by "the feature" since it is possible we all have different ideas in our heads what "the feature" is. The feature I'm talking about is to allow you to say something like
void Frob(params IEnumerable<int> x)
{
foreach(int y in x) ...
}
and then the call site can either be in the "normal form" of passing a sequence of integers, or the "expanded form" of Frob(10, 20, 30). If in the expanded form, the compiler generates the call as though you'd said Frob(new int[] { 10, 20, 30}), the same as it does for param arrays. The point of the feature is that it is often the case that the method never uses random access to the array, and therefore, we could weaken the requirement that the params be an array. The params could just be a sequence instead.
You can do this today by making an overload:
void Frob(params int[] x) { Frob((IEnumerable<int>)x); }
void Frob(IEnumerable<int> x)
{
foreach(int y in x) ...
}
which is a bit of a pain. We could simply allow you to use IEnumerable as the type of the params argument and be done with it.
Will this ever be fixed?
I hope so. This feature has been on the list for a long time. It would make a lot of functions work much more nicely with LINQ.
Frob(from c in customers select c.Age);
without having to write two different versions of Frob.
However, it is a mere "small convenience" feature; it doesn't actually add a whole lot of new power to the language. That's why its never made it high enough on the priority list to make it to the "specification is written" stage.
I really wish they would rewrite the old libraries to use generics.
Comment noted.
Ah, I think I may now have understood what you mean. I think you want to be able to declare a method like this:
public void Foo<T>(params IEnumerable<T> items)
{
}
And then be able to call it with a "normal" argument like this:
IEnumerable<string> existingEnumerable = ...;
Foo(existingEnumerable);
or with multiple parameters like this:
Foo("first", "second", "third");
Is that what you're after? (Noting that you'd want the first form to use T=string, rather than T=IEnumerable<string> with a single element...)
If so, I agree it could be useful - but it's easy enough to have:
public void Foo<T>(params T[] items)
{
Foo((IEnumerable<T>) items);
}
public void Foo<T>(IEnumerable<T> items)
{
}
I don't find I do this often enough to make the above a particularly ugly workaround.
Note that when calling the above code, you'll want to explicitly specify the type argument, to avoid the compiler preferring the params example. So for example:
List<string> x = new List<string>();
Foo<string>(x);
The params parameters are sent as an array, and an IEnumerable<T> doesn't provide the random access that is required to act as an array.
You have to create the array from the IEnumerable when you call the method:
TheMethod(theIEnumerable.ToArray());