investigate replacing IReadOnly interfaces with ref readonly feature

[voltcode]

Regarding: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/readonly-ref.md, I'd like to add some additional "success" conditions for that specification that may be useful for extending the spec in the future.

First of all, I believe that an ideal scenario with "ref readonly" would be to be able to replace all/most IReadonly* interfaces with this language feature. It would remove the need for interface dispatch, and make users of C# less confused about the way they should move towards allowing mutability only where absolutely necessary.

Secondly, I think the proposal should also attempt to push the feature downstream, so that JIT could one day use additional knowledge about immutability to optimize program behavior. I'm not sure what's the correct process is but I believe someone more knowledgeable here could start things moving for the greater C# and .NET in general.

Next, I think a discussion about C++ (const &) and other languages that addres "ref readonly" problems would bring much to the table, at least in terms of ease of use and "default" behavior for new users.

Another related, perhaps useful story for discussion is PureAttribute from System.Diagnostics.Contracts, which fulfils similar need. Contracts in C# are in my opinion lost opportunity (meaning low adoption), partly because the tool support and usefulness for optimization were mostly not implemented. A wide "Contracts" framework like concepts in C++ could open a wide array of enhancements on all levels - from language to JIT optimization.

I realize that original ref readonly feature is related to value types, however I believe making it into a feature like const& in C++ and getting rid of IReadonly references would be beneficial for the language.

[MkazemAkhgary]

note that IReadonly provides covariance conversion which is useful for collections, its not useless feature, in fact some programs already took great advantage of covariance. so getting rid of IReadonly at this point is not really applicable.

[voltcode]

I don't think I understand the use case that you have in mind, and why standard generic collections cannot work with covariance while being marked read only in a different way. Can you provide an example of where IReadonly<> is useful and standard interface version wouldn't work (provided that compiler gets the read only feature from a variant of readonly construct) ?

[VisualMelon]

@voltcode any time you cast a T[] to an IReadOnlyList<T> is a good start (something I do most days). The idea of deprecating interfaces with language-defined immutability is unworkable: interfaces are valuable because they are implementation independent: your suggestion assumes an implementation, and is duly inapplicable in a wide variety of situations; where it is applicable it will usually be inappropriate. It is not entirely clear to me how the current proposals for readonly ref even approximate the behaviour of IReadOnly* interfaces, but it is certainly not impossible to do so.

[benaadams]

@voltcode any time you cast a T[] to an IReadOnlyList is a good start (something I do most days).

Can do T[] -> ReadOnlySpan<T> now; which should be faster; but only works with contiguous memory

[VisualMelon]

@benaadams does ReadOnlySpan<T> implement IReadOnlyList<T>? I would assume it does, but I can't seem to find the docs for it...

[voltcode]

@VisualMelon I'll try to describe what I mean by a C++ vector example and C++ const methods and translate of it to a possible syntax with "readonly".

C++ Vector has an indexer: http://www.cplusplus.com/reference/vector/vector/operator[]/
it comes with two flavours, one of them is "const". Const is viral, meaning that if you take a const ref, you can only use const member functions on it (functions that don't modify class fields, call non const member functions).

Now to C#. IReadonlyList is basically IList without mutating methods. Translating the intention to C++ const methods, that would mean converting IReadonlyList -> const reference. If you use a const reference to IList, you are only allowed to use IList methods that are const/readonly.

It seems very similar to ref readonly methods mentioned here:
https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/readonly-ref.md#solution-1

public ref readonly T RefAt(int i)
    {
        // returning a ref readonly 
        return ref this.r1;
    }

a ref readonly method seems close to C++ const method in intention (albeit in my opinion less nice to read). I get that it is currently only aimed at value types at the moment, but as I mentioned before, I'd like to see this basic purity contract pushed to much greater utility.

[VisualMelon]

@voltcode thanks for the explanation! Nonetheless, for a T[] to implement readonly IList<T> this needs to be a type in its own right (i.e. a language-level IReadOnlyList<T>) and will always require 'interface' dispatch. (As is standard, I'm already confused by the proposal, but I don't see the value in having dedicated language support for such types). I am perhaps reading too much into the comment about interface dispatch in the OP, but I do think that most of places that this support would be applicable should be an interface anyway; though I cede that for performance critical code this could be a valuable addition.

[voltcode]

Well, getting rid of interface dispatch might not be possible in all situations as you say, but I think the biggest take away would be to use a single "readonly" feature that can be understood from language to JIT instead of multiple IReadonly* interfaces that make immutability an opt in characteristic. As in C++, users would have to be trained to use readonly by default (tooling can help by assisting as R# hints "field can be made readonly"). New readonly behaviour would be available for all code, not just collections - anyone designing an interface or a class would be able to define which methods are readonly (in C++ const method sense) and which aren't in the same interface - no need to define a mutating one separate from the non mutating one.

[VisualMelon]

New readonly behaviour would be available for all code, not just collections

How do you mean? (We are only using collections as examples because we all use the some ones every day!)

I'm interested to hear more about how you might suggest introducing a const like construct. const is more than an expression of intent, and to support it usefully would require a corresponding mutable field/propery modifier as found in C++ (so that const/readonly methods can still change internal state when they declare their immutable intent). This would be a significant addition, and putting it to use within interfaces would require massive changes throughout the BCL, but could well improve code standards considerably. My complaint with this sort of feature is that it is really about the implementation, not the intent: using const to define members of an interface is perfectly feasible, but it enforces immutability/explicit mutability, and means that an interface can heavily influence the implementation rather than just indicating intent; the benefit is all in the implementation (makes it harder to get it wrong and easier to reason within) but it also has its hands tied. The benefit is surely real, and if designing C# from the ground up, this would be an appealing feature for lots of reasons, but conceptually I'm not sure it is really applicable to interfaces (I'm not presently convinced that it is meaningful for an interface to ascribe meaning to the state of an implementation (rather than just expressing an intent), as appealing and practical as it may be... I shall certainly have to give this more thought)

There are obvious benefits to const style readonlyness (though I think you may have confused the existing intent of read-only refs, which merely prevent overwriting the target, not preventing the calling of potentially state-changing methods (these are distinct concepts that must remain distinct)) for code-quality (and performance in select places), but I'm less than convinced at the moment that it can (or should) replace IReadOnly interfaces, and I'm not convinced that it should be used in conjunction with interfaces at all. While IReadOnlyList<T> is (necessarily) a subset of IList<T>, it has more purpose than just being a readonly IList<T>, and explicitly defining readonly interfaces for anything (collection or otherwise) will always be invaluable.

[voltcode]

Question - I agree that linking "const method" behavior is not well related to ireadonly collections. Should I close this issue to avoid further confusion and create new one for "const method" kind of behavior?

[VisualMelon]

I really have no idea how this forum is meant to work - I wouldn't wish to suggest any particular course of action - but I don't suppose there would be any harm in starting a more focussed discussion with a few more 'ground assumptions' in the issue statement. I'd certainly be interested to read some more discussion on these matters.

[bbarry]

@VisualMelon

does ReadOnlySpan<T> implement IReadOnlyList<T>? I would assume it does, but I can't seem to find the docs for it...

No.

• A ref struct type may not be declared to implement any interface

https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/span-safety.md

more span docs:

https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md (good)
https://docs.microsoft.com/en-us/dotnet/api/system.span-1 (pretty worthless)

[VisualMelon]

@bbarry thanks for the clarification, and for the links (searching is not a strong point here). I'd better read them properly at some point, though I note that there is no mention of IReadOnlyList<T> anywhere... if these things have to be on the stack, I'd assume membership wouldn't be possible, so they will have to be orthogonal (duly, neither is redundant, to provide some modicum of relevance to this issue).

[bbarry]

I think the fact that ReadOnlySpan<T> does not implement IReadOnlyList<T> does point to a logical inconsistency in an abstraction somewhere, but I'm not sure where. Spans are very clearly things that we want to index into and have an item count and can enumerate. Clearly .NET would be more logical if ReadOnlySpan<T> did implement it. On the other hand, the Span types are these low level things that are very efficient BECAUSE they are constrained in such a way that causes bad things to happen when they escape the stack (which would happen if you casted them as an interface).

This is certainly orthogonal to the concept in this issue of somehow using readonly ref to denote various forms of ReadOnly-ness currently done by contrived type system de-facto patterns which are inadequate.

[CyrusNajmabadi]

I'm confused. Isn't ReadOnlySpan a ref struct? If so, then it can't implement interfaces at all. Nor would it be beneficial to do so. It can't be passed to anything that takes an interface (since you'd have to box them, and that would break the invariant that they're stack only).

Spans are very clearly things that we want to index into and have an item count and can enumerate.

Sure. But why do you need IReadOnlyList for that? It sounds like you just need an indexer, a count, and the ability foreach.

--

Note: this sounds like something that would fit into Shapes (#164). Here, ReadOnlySpan and Span could fit the 'Shape' of these sorts of types, without ever having anything to do with interfaces and whatnot.

[VisualMelon]

I'm confused. Isn't ReadOnlySpan a ref struct? If so, then it can't implement interfaces at all

@CyrusNajmabadi rather: bbarry has already spoiled the surprise (and righted my previous misunderstanding).

Nor would it be beneficial to do so. It can't be passed to anything that takes an interface (since you'd have to box them, and that would break the invariant that they're stack only).

Do not forget about runtime monomorphisation of structs (as type parameters) which implement interfaces (a feature I truly adore, though I may have the name wrong). It isn't presently clear to me why generic ref like types with interface implementations exposed through generic constraints would be impossible (though are blatantly not convertible, as we can all now agree): this would seem an invaluable feature (and allow Span<T> to implement IReadOnlyList<T> - if only in a generic capacity - and preserve all of the performance of an explicit type at compile time (excluding JIT overhead)).

I do have to wonder what IReadOnlyList<T> is if not the de facto standard interface for an indexer, a count, and the ability to foreach!

[benaadams]

@VisualMelon a generically constrained method can still violate stack-only as it doesn't prevent boxing in method:

object DoThing<TList, T>(TList thing) where TList : IReadOnlyList<T>
{
    return (object)thing;
}

It would also have to be a non-boxable ref-type constraint

[jnm2]

@VisualMelon I believe the term is 'generic specialization.'

[VisualMelon]

@benaadams indeed, it is not convertible; however, if the generic is explicitly a ref type, the compiler can know not to allow that, as you say. I would reckon on the value of generic constraints on such types being considerable (honestly, it seems an obvious feature that would warrant serious consideration, but I'm probably still missing something).

@jnm2 thank you kindly, though I think that is a more general term than the one I'm looking for (I really only care about runtime specialisation over (ref) structs, which could (I reckon) allow support for projection as an interface, though as benaadams points out, the syntax is going to be a problem)!