C＃IReadOnlyList <t> 防护立即被垂头丧气所破坏，还是我错过了一些东西？

Question

Given the below: Is it truly the case that if an IReadOnly(of T) was conceived from an extant MutableEquivalent(of T), that simply casting to the mutable version allows full access, and changes to an object others may rely on to have static elements/count? The output below shows my "THIRD INJECTION" string, despite iterating through a read only collection. Is it just manners and self control that prohibit casting a readonly collection down? Are you supposed to see the interface provided, and bear its restrictions, cast-invariant, due to type alone? Thanks for any clarification on what this interface and others like it truly promise/guarantee.

EDIT- This is not a duplicate of IReadOnlyCollection <T> vs List.AsReadOnly() since I didn't mention List.AsReadOnly() in my question, nor IReadOnlyCollection. Those were introduced by responders. This was a question on underlying mutable list exposure when behind an IReadOnly interface. There are some overlaps in some comments, but a question such as "What does IReadOnly actually do for its underlying mutable List(of T)?" duplicates the spirit of my question. Not "What is the difference between these two entities pertaining to read only?", since I only mentioned one.

static class Program
{

    public static void Main()
    {
        List<string> hack = (List<string>) READONLY;
        hack.Add("THIRD INJECTION");

        foreach (var s in READONLY)
        {
            Console.WriteLine(s);
        }
    }

    public static readonly IReadOnlyList<string> READONLY = new List<string>{"@0", "@1"};

}

Answer 1

From your comment :

I didn't realize the interface was more a loose protection for a programmer rather than a 'const'-esque' barrier to mutation. … I assumed, incorrectly, that a downcast from a readonly to mutable would be an invalid cast.

An interface isn't intended as "protection" of any sort, at all. It is simply a promise to implement specific features.

The benefit of IReadOnlyList<T> is one of semantics and now, with generic type variance in C#, flexibility. The semantic benefit allows you to expose a list in a way that expresses the intent to only read it and not modify it.

The flexibility comes in, because the type parameter can be made covariant. This allows implicit conversions from IReadOnlyList<T1> to IReadOnlyList<T2> where T1 inherits T2 .

It is up to the implementor of the interface to decide whether true immutability is provided or not. If you want a collection to be truly immutable, you would use ReadOnlyCollection<T> as the implementation for IReadOnlyList<T> , instead of List<T> . You can pass any IList<T> implementation to the ReadOnlyCollection<T> constructor, and the new object will expose that IList<T> object's data without allowing modification (directly…you can always, of course, cheat with reflection, even with a object that is truly immutable and not just a wrapper like ReadOnlyCollection<T> ).

With any interface, you are always only dealing with a specific object, which has a specific type, that type always implements some functionality, and can always be cast to the original type, as well as any other interfaces it might implement.

It would be a mistake to think of interfaces as in any significant way a form of protection . They aren't. They just express what an object is able to do .

Answer 2

The underlying collection of READONLY is a mutable list, this is the reason that the cast actually succeeds when creating the hack variable. READONLY is read-only for any of its consumers, but the underlying list can still be mutated.

UPDATED : As Sir Rufo pointed out, exposing the list by way of list.AsReadOnly() will prevent hard casting.