C++ makes this (and many other things!) needlessly painful.
In C# it is just
return numbers.Sum();In C# it is just
return numbers.Sum();The one-liner approach tends to include an explicit type declaration (Or turbofish), `iter()`, and `collect()`, at minimum.
x.iter().sum()This sounds like someone complaining that the concepts they learned when they were first starting out are the only concepts that programming languages should introduce which is silly - technology evolves as we find better and new ways of accomplishing old tasks.
In Rust you would probably just write: x.iter().sum()
Only collections of numeric types (including arrays) have Sum.
https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...
Historically, constraining generic arguments on addition was problematic - the full feature set of numeric types was "lifted" to be fully representable through generics only recently[0].
With that said, there is an open proposal[1] to introduce additional generic math overloads to IEnumerable<T> methods, but it hasn't seen much activity as the existing overloads cover most commonly used numeric types already.
[0]: https://learn.microsoft.com/en-us/dotnet/standard/generics/m...
May as well ask, "where did x come from, and why are you so sure you can iter().sum() it?"
C# has generic types, so yes, C# arrays of numbers have a Sum method.
https://stackoverflow.com/questions/2419343/how-to-sum-up-an...
Don't make bold dismissive comments about things you are ignorant of. It makes you look Blubby.
You'll see that a few of those SO comments actually say they're relying on LINQ to make that work. The array type doesn't have such a method itself.
So, in reality although many C# programmers will think of this as "correct" it just won't even compile... except if there's already LINQ.
The performance profile of LINQ, while much maligned, has been steadily improving over the years and, in the example of Sum itself, you actually do want to use it because it will sum faster than open-coded loop[0].
I do have grievances regarding LINQ still - my (non-negotiable) standpoint is that Roslyn (C# compiler) must lower non-escaping LINQ operations to open-coded loops, inline lambdas at IL level and similar, making it zero-cost - .NET (IL compiler/runtime) provides all the tools necessary to match what Rust's zero-cost-ish iterator expressions offer and there just needs to be more political will in the Roslyn teams to do so. Because of this, I'm holding my breath waiting for DistIL[1] to be production-ready which does just that.
[0]: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
[1]: https://github.com/dubiousconst282/DistIL
(I don't understand what you mean by "it won't compile", because it will, in most cases System.Linq namespace is already referenced anyway, either through global usings or at the top of the file)
The "in most cases" is doing all the lifting here. Rust's Iterator is in the prelude. Even if you #![no_std] you get the core prelude which has core::iter::Iterator. You would need to explicitly write code to tell Rust "No, I don't want the prelude" to get rid of it, I'm sure people do that, otherwise it wouldn't be possible, but few enough that I've never seen it.
But in C# there is no such promise. In most (but not all) real world C# projects somebody already brought in LINQ. If you're using a technology that gives you a "ready to go" standard C# project template it undoubtedly folds in LINQ too. But it's not actually provided by the language and that's a meaningful gap.
Notably in several of the playground type tools, since LINQ is not there by default this won't work - like I said it won't compile and it doesn't suggest "Oh you need LINQ" because the C# compiler doesn't provide such suggestions.
LINQ aka IEnumerable/Iterator methods are usually imported by default, something like with prelude. As others said, they are part of standard library.
I'm not sure what you are arguing against either but whatever your criticism is - it is misplaced as C# and Rust roughly belong to the same Venn diagram of features against commonly held beliefs.
You can test it yourself:
sudo apt install dotnet-sdk-8.0
mkdir TestConsole && cd TestConsole
dotnet new console
var numbers = Enumerable.Range(0, 10).ToArray();
var sum = numbers.Sum();
Console.WriteLine(sum);
It's not literally a method (it's not, for instance, in the vtable of some array class), but as far as their API is concerned, yeah, they do: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...