C# is fantastic, if only List 'd respect Remove&Return [closed]

Question

In the domain of system-modeling (e, systemVerilog, matlab, phyton), lists are obsoleting arrays, stacks and queues(*) altogether. Other domains that use python, perl and ruby have that same mindset, as well.
I am a system-modeler and a List aficionado that is new to c# and java (for hi-school teaching). c# seem so great ..but...

The Remove&Return approach is respected by :

C# Stack, C# Queue, Java ArrayList ,Python list, Perl, Ruby, e, systemverilog and others.

A notable exception is ... C# List.

c# List<T>.RemoveAt(idx) doesn't return a value.

Why is that important ? Say one wants to post this in a modeling web site (who aren't experts in c#):

 int len=myCriticalProcessList.Length; sendMethod( myCriticalProcessList.RemoveAt(len - 1)  );

That seem to work for any modern language, but to post it in c#, one has to also post several more lines, and invent new names. Also one doesn't need to know the type of the list! And when the type is changed, he does not need to change his code at all. Also naturally System modeling folks care about advanced c#, as much as c# folks care about advanced system-modeling (i.e none).

Can there be any damage if a value is returned in that case? Is there a performance consideration here? Does Java-value-return in arraylist.remove, make it slower, or less safe? Is c#'s remove&return approach good for Stack, and Queue, yet not a good idea for List? Is there some difference in underline implementation, or philosophy ?

Side note:

• C# Stack.Pop and c# Queue.Dequeue do return a value. (a remove&return approach, like Java remove, and unlike c# RemoveAt).

• Python's list.pop([idx]), removes-element-by-position, and returns a value. Similar to remove in java ( yet with a default, remove&return the last element).

• C++ (stl) remove, is also void (thanks @Deduplicator). Yet, decisions relevant for languages without native-built-in-garbage-collection, are not always relevant for GC langs.

Seem @Deduplicator comment points us to the answer!!

C# was inspired by c++ not only in it's name, but also in many other things.Additionally, C# compiler was developed in C++ (in it's first ~15 years). Find me one human that is not influenced by the language he is using ... No one says it's better than Mads Torgersen, the program manager of c# : "Working in C# every day makes you think differently about C#: It’s the power of “dogfooding”." https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98

(*) minor: queues are not 100% obliterated by lists. There're very rare cases in system modeling were O(n) for dequeue is not tolerated.

Answer 1

Typically, people remove things from lists already knowing what those things are, as that knowledge is why they want to remove the item in the first place. By contrast, people don't usually want to remove specific known items from a stack/queue, but rather retrieve the first/last element.

Probably relevant factors:

1. Consistency with List<T>.Remove(T).
   A List<T> has a .Remove(T) method that returns a bool indicating if the removal was successful. So, for consistency, we'd expect .RemoveAt(int) to do the same. Except .RemoveAt(int) can't really fail (unless the index is out-of-range, in which case it throws an exception instead), so it just returns void instead.

2. Removing an item from a list doesn't imply retrieval.
   Queues/stacks are all about specific process models in which things are queued/stacked and then dequeued/popped for processing, such that removal and retrieval are conceptually linked together. By contrast, lists don't inherently imply such an operational model.

3. Retrieval is readily available for when someone would want it.
   If a caller would want to retrieve the item at the index before removing it, then they can just specify that with list[index].

It's worth noting that a hypothetical ConcurrentList<T> would've probably implemented

partial public class ConcurrentList<T>
{
    public bool TryRemoveAt(
                int targetIndex
            ,   out T successfullyRemovedItem
        )
    { /* ... */ }
}

, analogous to a similar .TryRemove(T_Key, out T_Value) for ConcurrentDictionary<T_Key, T_Value>'s.

Finally, the main use-case of List.RemoveAt() is probably something like:

for (int i=0; i < list.count; ++i)
{
    if (someConditionalCheck(list[i]))
    {
        list.RemoveAt(i);
        break;
    }
}

, where it's important to note that break;, since if the loop continues without breaking after removal, then it'll skip an element. This could be fixed by also manually decrementing i, e.g. --i instead of break;, but at that point the code's getting pretty twisted. Plus it'd be poor form to try something like this without a break;, anyway, as list-removal is O(n), making it a poor choice of data structure to use if someone expects to loop over multiple removals as that could be O(n²).