Can anyone explain why properties cannot directly extend an accessor when inheriting?

[zms9110750]

Actually, what I want to ask is, why does IList not inherit IReadonlyList.
I tried writing an interface that inherits IReadonlyList. However, only the parent class's indexer can be hidden. Although the default implementation can be used now, the new indexer is still different.

[CyrusNajmabadi]

Actually, what I want to ask is, why does IList not inherit IReadonlyList.

Because then someone could downcast an IReadOnlyList to an IList and mutate it, violating the contract.

[zms9110750]

But I believe that the concept of interfaces only allows for defining what must be implemented and does not have the authority to decide what cannot be implemented.Object may also be a valid int. People should not be prevented from using this object to implement intd.
If they really want to violate the protocol, the current List will be used as the ReadonlyLIST parameter. He can still convert ReadonlyLISt to IList. The only ones who were injured were the ones we received the IList and wanted to convert to readonlyLISt.

[CyrusNajmabadi]

If they really want to violate the protocol, the current List will be used as the ReadonlyLIST parameter

It can't be. List<T> doesn't implement IReadOnlyList<T>. For this very reason.

[zms9110750]

What?you see :https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.list-1?view=net-7.0.
List implements IReadOnlyList

[CyrusNajmabadi]

Sorry, i got confused over IList and IReadOnlyList. Apologies :)

[jnm2]

@CyrusNajmabadi I don't agree with this. Downcasting is always risky, not more so from IReadOnlyList to IList than from IReadOnlyList to List.

[CyrusNajmabadi]

However, only the parent class's indexer can be hidden. Although the default implementation can be used now, the new indexer is still different.

I'm not sure what this means.

[CyrusNajmabadi]

This seems to work just fine for me: https://sharplab.io/#v2:CYLg1APgAgDABFAjAFgNwFgBQWCWA7AFwFMAnPAQwBs59iSAzcgYyJpKPOAHs9KBPSjgDOBADwAVAHxYA3lgCQ4uAQAWwgNq0aeYEQAeAXTgy4AcyIFUcAL5Zb2TLVIVqThs1Y5BIiZLgg2Dm5eAWExKVkFJVUNLXxdQ2MzCyshFJs7LFxCZyoEACY4b3C/AK8w30jMeSgAZjhotSFNQm0Egyw4LuNO7r7zAjgAXj9VEi4Adzg8IimkADoAOS4CAEkAWwAHSiJ1ohzgAFE9Fk2CHB4ACgBKDEw+vrTBkeUVcamZucQllY3t3f2xCOJyIZwueBudz69msQA==

[zms9110750]

internal interface IPoint
{
	(int, int) Point { get; }
}

internal interface IPoint<T> : IPoint
{
	T Value { get; }
}

internal class Point : IPoint<int>, IPoint<string>, IPoint<bool>
{
	int IPoint<int>.Value => throw new NotImplementedException();

	string IPoint<string>.Value => throw new NotImplementedException();

	bool IPoint<bool>.Value => throw new NotImplementedException();

	(int, int) IPoint.Point => throw new NotImplementedException();
}

You see, when a prism inherits to the same interface. The content of this interface is only one copy.
When I use IPoint, IPoint, IPointseparately, the (int, int) Point {get;} I receive must be consistent.
I hope that the get of {get; set;} on the derived interface is consistent with the get of {get;} on the base interface.

[CyrusNajmabadi]

I hope that the get of {get; set;} on the derived interface is consistent with the get of {get;} on the base interface.

That's what my example showed. It's the same 'get'. If you want to require that it must be the same 'get', then an analyzer would work here.

[zms9110750]

What I mean is that when the implementer actively wishes to give different implementations to the two, it also makes it impossible for them to do so.

[CyrusNajmabadi]

Yes, i understood that :) You can accomplish that with an analyzer that ships with your interface.

[KyouyamaKazusa0805]

Because interfaces offer an OOP concept for "can do" relationship. IList<T> is a type that wants to tell you all types having been implemented this interface can do what things that lists do. IReadOnlyList<T> is a type that wants to tell you all types having been implemented this interface can do what things that read-only lists do.

IList<T> makes a list behave more like a list, providing with functions allowing you adding, inserting, removing elements; however, a read-only list cannot do such operations because it is read-only.

So, I'll tell you why List<T> implements IReadOnlyList<T> but IList<T> not: because List<T> is a real type that you can create an instance to be used, behaving like BOTH a normal list and a read-only list, but IList<T> is designed to make an implementation type behave like a normal list rather than a read-only one.

Suppose if you can design APIs for C#, please consider: what members can be defined for a read-only list? Obviously, a read-only list can only be iterated and fetched internal elements. This is what members that IReadOnlyList<T> defines:

There's a coincidence for that indexer: both IList<T> and IReadOnlyList<T> can be iterated, so both they contain an indexer. However, IReadOnlyList<T> can only fetch elements - you cannot modify the internal values, so the indexer defined in IReadOnlyList<T> only contain a getter. This doesn't mean IList<T>.this[int] extends from IReadOnlyList<T>.this[int].

In short, use just a sentence to conclude:

You cannot make IList<T> implement IReadOnlyList<T>: they are same-level interfaces standing for different kinds of lists, providing with different usages of lists.

If you want to do the same thing you've considered, just change to another way to approach.

[zms9110750]

If I were to do it, I would make it this way

internal interface IReadOnlyCollection<out T> : IEnumerable<T>, IEnumerable
{
	int Count { get; }
	bool IsReadOnly { get; }
}

internal interface ICollection<T> : IReadOnlyCollection<T>
{
	void Add(T item);

	void Clear();

	bool Contains(T item);

	void CopyTo(T[] array, int arrayIndex);

	bool Remove(T item);
}

internal interface IReadOnlyList<out T> : IReadOnlyCollection<T>
{
	T this[int index] { get; }
}

internal interface IList<T> : ICollection<T>, IReadOnlyList<T>
{
	T IReadOnlyList<T>.this[int index] => this[index];
	new T this[int index] { get; set; }

	int IndexOf(T item);

	void Insert(int index, T item);

	void RemoveAt(int index);
}

The problem with this design is that it has two indexer.
If the implementer uses display implementation and implements it separately for them, it will not be expected.

[yaakov-h]

The other problem with this design is that you could have an IReadOnlyCollection where IsReadOnly is false, which makes no sense.

[zms9110750]

I don't quite understand why an IsReadOnly attribute appears in an interface with an Add method too.

[Joe4evr]

I don't quite understand why an IsReadOnly attribute appears in an interface with an Add method too.

I'm guessing it's primarily to cater to the scenario of "freezing". The collection can initially be populated like a regular list, then an internal method flips the IsReadOnly flag to true, and all the methods that would otherwise modify the collection will throw an exception instead, while avoiding an extra allocation.

From what I understand, this can be quite a common scenario in UI stacks like WinForms and WPF, so I wouldn't be surprised if those teams were the ones asking for it at the time.

[TahirAhmadov]

@Joe4evr hmm, I've been using WinForms for a while, and cannot think of any place in it where such collections exist of the top of my head. And WPF was created significantly later than IsReadOnly property, and while I did use it, I'm not a pro in it, but still, I don't recall any such collections in WPF, either. Still, I would have preferred it was a separate interface, like IFreezableList or something like that. Oh well, water under the bridge now.

[Joe4evr]

@TahirAhmadov I didn't say the developer was the one making use of such collections. I guess I could've been clearer, but what I meant was that such collections are used inside the UI components. So maybe you don't always see them, but they're still there.

[zms9110750]

For the design issue of IReadOnlyList, let's rethink why we should use it.
I have a component that, in order for others to freely choose, my API will use IList as a parameter.
Then, some of my subcomponents will display the data, which they only need to display and cannot change, so I gave them IReadonlyList as a parameter

internal class Foo
{
	private IList<int> list;

	public Foo(IList<int> list)
	{
		this.list = list;
	}
}

internal class Boo
{
	private IReadOnlyList<int> list;

	public Boo(IReadOnlyList<int> list)
	{
		this.list = list;
	}
}

But how do I convert IList to IReadOnlyList?
If we only need type matching, we can do so.

	public Foo(IList<int> list)
	{
		this.list = list;

		Boo boo = new Boo(list.AsReadOnly());
	}

Is this what we want?
Why do I want to reference my own IList to others?
Because I want them to receive the changes immediately when I make the changes.
But what I gave them was a new instance, and they couldn't observe any changes.

[CyrusNajmabadi]

Because I want them to receive the changes immediately when I make the changes.

This is possible. Just have a type that implements both interfaces. Or pass a wrapper that implements IReadOnlyList but calls through to the underlying list.

[CyrusNajmabadi]

@zms9110750 it's unclear what you'd like the language to do here. IList/IReadOnlyList aren't part of C#, they are part of the BCL.

[CyrusNajmabadi]

you keep writing it as an explicit impl. The link i provided shows how you do not need that.

[CyrusNajmabadi]

As also mentioned, you can write an analyzer if you want to block this legal usage of these language constructs.

[zms9110750]

What I mean is, if {get;} can be extended to {get; set;} in inheritance. Can keep only one indexer.

[CyrusNajmabadi]

What I mean is, if {get;} can be extended to {get; set;} in inheritance. Can keep only one indexer.

Yes. I linked to that.

[zms9110750]

Okay, I study it.

[huoyaoyuan]

Actually, what I want to ask is, why does IList not inherit IReadonlyList.

A historical fact: the readonly interfaces (.NET Framework 4.5) comes way after non-readonly generic interfaces (.NET Framework 2.0).

"Moving" the declaration of interface member to base interface is a breaking change, since it will break explicit interface implementation. If we redesign the interfaces today, the read-write interfaces will probably inherit from corresponding readonly ones.

[TahirAhmadov]

If BCL wanted to "insert" IReadOnlyList<T> into the inheritance chain by changing IList<T> to inherit from it, I'm guessing there is no way to somehow combine the get-only indexed property of IReadOnlyList<T> with the get/set indexed property of IList<T>, correct?
I ask because if the above is incorrect, we're left wondering why they didn't just do it...

[DavidArno]

I ask because if the above is incorrect, we're left wondering why they didn't just do it...

Presumably for the same reason that ImmutableList<T> implements IList<T>. Lots and lots of C# code expects an IList<T> but doesn't mutate the list as IList<T> dates back to .NET 2.0, whereas IReadOnlyList<T> didn't appear until .NET 4.5. Therefore the pragmatic solution is to offer up an apology to Mrs Liskov and have everything new implement IList<T> to maximise their usefulness.

[jnm2]

It was a while ago, but I believe I heard the API design team mention in one of their videos that they wish they could make IList inherit IReadOnlyList, but the binary break prevents this.

[zms9110750]

Do some people believe that there should be a restriction on a class or interface that cannot achieve something?
In today's environment, I believe that ReadOnly appears on the name and has no right to demand that the implementer not do anything. It's more like saying I'm sorry, I can only do this for you.
If the requirement cannot achieve anything, then something else must be needed.

[DavidArno]

Do some people believe that there should be a restriction on a class or interface that cannot achieve something?

This is the whole point of the interface segregation principle: only have interfaces specify what's needed and only implement those interfaces that are truly needed. So if we were designing lists from scratch now, likely we'd have IReadOnlyList<T> and IEditableList<T>. Then List<T> would implement both and ReadOnlyList<T> would only implement the first interface.

But these things were designed 20 years ago in some cases and so we are stuck with the various decisions made back then that we'd want done differently these days.