1

If I execute the following code in .Net Core 6, C# Version 10 ...

        int[] arrInts = new int[] { };
        string[] arrStrings = new string[] { };
        Console.WriteLine($"arrInts.Length     ==  {arrInts.Length}");
        Console.WriteLine($"arrStrings.Length  ==  {arrStrings.Length}");
        arrInts.Append(13);
        arrStrings.Append("13");
        Console.WriteLine($"arrInts.Length     ==  {arrInts.Length}");
        Console.WriteLine($"arrStrings.Length  ==  {arrStrings.Length}");

... the code executes, & length stays 0 after the .Append(...) statements.

But if arrays in C# cannot be changed, then why does the method .Append(...) exist on arrays?.. & what does it actually do when you call it?

Why does it not throw an error?...

Based on comments, I understand / know that I can do the following:

        arrInts = arrInts.Append(13).ToArray<int>();
        arrStrings = arrStrings.Append("13").ToArray<string>();
        Console.WriteLine($"arrInts.Length     ==  {arrInts.Length}");
        Console.WriteLine($"arrStrings.Length  ==  {arrStrings.Length}");

... because .Append(...) comes from IEnumerable<TSource> Append<TSource>

But that seems counter-intuitive, no? .Append(...) should actually 'append', no? One would think it would do the .ToArray "under the hood", so that it "appends".?.

Or should the method have really been named: ToIEnumerableWithAppend?

George 2.0 Hope
  • 583
  • 1
  • 6
  • 21
  • 3
    You're calling [`Enumerable.Append`](https://learn.microsoft.com/dotnet/api/system.linq.enumerable.append), which is meaningful (though discarding the result is not). – Jeroen Mostert Mar 08 '22 at 15:36
  • 1
    If method return value is not void always assume that it returns the result, and that this result is an object different from the one you started with. – Dialecticus Mar 08 '22 at 15:48
  • 1
    ".Append(...) should actually 'append', no?" - this comes down to what type of glasses you have on and whether you prefer methods to *modify* the values they're called on or to *return* a mutated value and leave the original alone. Both can be perfectly valid choices and, in either case, if you're expecting the item to be appended, `Append` seems like a good name for the method. – Damien_The_Unbeliever Mar 08 '22 at 15:48
  • @Damien_The_Unbeliever I understand that... this is a *return* method... the issue I have, if you go that route, is that it is not "returning an array" (which I think is the logical conclusion if you're "appending" to an array) instead it "returns" an `IEnumerable` – George 2.0 Hope Mar 08 '22 at 15:52
  • 1
    The method *takes* an enumerable and returns an enumerable. It's a *more general* method. Array happens to be one of many types that is enumerable. – Damien_The_Unbeliever Mar 08 '22 at 15:53
  • @Damien_The_Unbeliever but that's not 100% true, yes? I can't do the following: `arrInts = arrInts.Append(13);` ... which is what one would *expect* to be able to do.?. – George 2.0 Hope Mar 08 '22 at 15:55
  • 1
    An array is an enumerable. This method takes an enumerable and returns an enumerable, but offers no guarantee that it's returning the same *type* of enumerable. And so, of course, if you have a variable for storing *one specific type of enumerable*, you're not guaranteed to be able to assign the return value back to it. – Damien_The_Unbeliever Mar 08 '22 at 15:57
  • @George2.0Hope, I think all of your confusion stems from an incomplete understanding of how extension methods work and what they are for. – Kirk Woll Mar 08 '22 at 15:58
  • @KirkWoll ... I'm guessing that's just a tradeoff of having extension methods then ... in that the method names are sometimes not *literal* ... something to keep in mind I suppose when I'm developing libraries for other developers to use. Thanks. – George 2.0 Hope Mar 08 '22 at 16:06
  • They are about as literally named as all the methods in the collections in the `System.Collections.Immutable` namespace. It's worth playing with those, as if you're not used to the pattern it's a great way to wear the other "type of glasses" Damien mentioned. – Kirk Woll Mar 08 '22 at 16:18
  • @JeroenMostert I think both the scope & purpose of this question is different than the question you're referring to as a duplicate. I would ask that you un-close this question, as I believe the answer to this question is valuable from language understanding perspective, not an implementation perspective. – George 2.0 Hope Mar 08 '22 at 16:41
  • First of all, I'm only one of the people who voted for the dupe, not even the first. Second, inasmuch as your question is "new" or "different", it's subjective. Whether or not it's counter-intuitive or what the method "should have been called" or even what it ought to do when fed an `Array` specifically is idle speculation. It is what it is; it's quite probable the designers were not initially aware that this particular interaction would be both common and confusing, and by the time anyone noticed it was too late to change. – Jeroen Mostert Mar 08 '22 at 16:53

0 Answers0