On Mon, Jul 8, 2024 at 1:12 PM Stephen Reay <
[email protected]> wrote:
So really the question should be: why do you feel the need to
*disallow* a combination that has no technical issues, and works
already? If you're going to disallow abstract why not disallow any
class inheritance at all? Because that's what abstract relates to:
class hierarchy. Why remove some support but keep the rest?
The reason to remove abstract was because it was thought
static means the same as
abstract. That is, neither can be instantiated. However, clearly that is short-sighted as Alex's example proves. That is, we cannot simply replace
abstract with
static because that precludes us from having an incomplete definition where some methods are still not yet implemented. As such, I am quite convinced by your arguments, and will make the change to add
abstract support back in; mainly because removing abstract support defies our fundamental razor (it's something we can already do).
If we support inheritance for static classes, we should allow static on both interface and abstract classes.
What do you mean by /allow static on [...] interface/? Are you saying you also expect to see static interface support? (This is something I am absolutely not considering at this time, without a very good argument in favour of).
Cheers,
Bilge