Proposal: Completeness checking via access modifiers

[gafter]

@alrz commented on Sun Feb 07 2016

Since the completeness of a certain hierarchy is not guaranteed only when it's public, I want to suggest that every class with at most the following access modifiers to be considered as complete patterns.

• private
• internal
• private protected

This should also work for public classes that have constructors with at most these access modifiers.

---

@HaloFour commented on Mon Feb 08 2016

You intend this to require CLR changes? Some of this could be enforced through internal and private protected access modifiers. But currently if you have a public type that isn't sealed (middle of the hierarchy) and is publicly creatable there'd be no way to prevent outside assemblies from defining their own types that derive from it.

---

@alrz commented on Tue Feb 09 2016

@HaloFour Treating internal hierarchies as complete patterns doesn't need CLR change (which is the main subject of this proposal), however, in #188 it is not clear that it does need nesting classes or not. But as I said sealed abstract isn't really good enough option here, because closeness of a type hierarchy is directly related to its access level. So I think to represent a public closed hierarchy it'd be better to use an access modifier rather than mixing abstract and sealed which doesn't make sense really and limited to an abstract root. A type being sealed or just externally sealed is orthogonal to the fact it is abstract. I proposed public protected to represent a public type that is sealed outside of its own assembly (this probably needs CLR support, just like #188 as if it doesn't need nesting). Meanwhile, all the other internal classes already have this quality and would be considered as complete patterns.

---

@HaloFour commented on Tue Feb 09 2016

I was asking about that public protected modifier, which of course does not exist in the CLR, nor does the concept of externally sealed. To enforce that without CLR changes you'd have to require that each class in the hierarchy cannot be publicly created and must have constructors of private, private protected or internal accessibility.

---

@alrz commented on Tue Feb 09 2016

@HaloFour I need to know, how this supposed to work (from #188)

abstract sealed class C {}
public class C_1 : C {}
public class C_2 : C {}
   ...
public class C_n : C {}

Does it emit nested classes? Is C intentionally left as internal? And there is no sealed on other classes, does it mean that they are implicitly sealed? If so, that means I cannot have a class like public class A : C_1 { }?

All in all, my intention here is to bring completeness checking to existing classes accourding to their access modifiers, that's it.

---

@HaloFour commented on Tue Feb 09 2016

@alrz

From that proposal:

Under Design 2, marking the root type of a hierarchy as abstract sealed will cause the structure from Design 1 to be generated by the compiler in lowering.

So yes, C_1, C_2 and C_3 would be nested types to C, even if they aren't written that way.

---

@alrz commented on Tue Feb 09 2016

@HaloFour Alright then. I've updated the opening post.

---

@HaloFour commented on Tue Feb 09 2016

Out of curiosity what is the benefit of the syntax of this proposal over enum classes #6739 ? Is that proposal more for the simple record type while this intends to permit hierarchies of more complicated classes? I think enum class is more clear as to the relationship between the abstract parent types and the closed set of derived types, and I prefer that to having the compiler automatically take what appears to be top-level classes and making them nested.

Otherwise I think it might be useful to propose a CLR change to allow for a type-hierarchy to be considered sealed beyond the assembly while still allowing for public constructors on intermediate types.

---

@alrz commented on Tue Feb 16 2016

@HaloFour There is no additional syntax proposed here (actually public protected wasn't that straight to the point, and perhaps if we want a notation for externally sealed classes we might use another keyword, at first I misinterpreted #188 as it is not applicable in some cases). This proposal is more about considering an internal type hierarchy (no matter if they are records or not) as a complete pattern i.e. switch expression wouldn't complain if you catch all the cases so a catch-all case woudn't be needed (because you can use any type in patterns and with #8415 you might even use positional deconstruction; I'm not really a fan of it though and I believe it should be worked around via extension is operators). That said, since record inheritance was under question at #206 I thought that it might be not really a problem if compiler already knows about the whole class hierarchy.

I think it might be useful to propose a CLR change to allow for a type-hierarchy to be considered sealed beyond the assembly while still allowing for public constructors on intermediate types.

That definitely affects #188 implementation and would allow (safe) record inheritance for public types as well which is nice of course, but I didn't aim for that here.