Why can't a method be virtual AND static at the same time?

[Frustrated]

On Wednesday, 29 January 2014 at 15:30:38 UTC, Martin Cejp wrote:
> On Wednesday, 29 January 2014 at 15:21:54 UTC, Frustrated wrote:
>> No, you are mixing concepts. Logger.print is a function that 
>> uses
>> a vtable and takes a hidden parameter this.
>>
>> ConsoleLogger.print is a regular function that is not in a
>> vtable(because it is static) and does not take a hidden
>> parameter(again, because it is static).
>>
>> So, when you do ConsoleLogger.print how the heck would the
>> compiler know which one you meant to use? While this might 
>> have a
>> solution, in some cases in general a virtual method REQUIRES a
>> virtual table and by using the keyword static on a function you
>> are saying it is not part of the virtual table.
>>
> Guess what: I DON'T CARE.
> No really, I don't care at all about the implementation details.
> If you look at it from the purely semantic view, there's no 
> ambiguity: got an instance? call the instance method. no 
> instance? call the static one.
>
> Technically, yes, there would need to be two methods generated 
> because of ABI differences, but this could be done behind the 
> scenes. By making a method both override and static, you'd tell 
> the compiler to do exactly that. Of course, the question is 
> whether this would really be worth implementing and based on 
> the reactions so far, I guess the answer is Not at all. I'm 
> surprised that nobody else misses this feature, though.

I don't care either. It's not that I don't disagree with you but
I simply no longer care any more. I would care, and assuming such
a thing mattered then I could care. I just don't any more....