I suggest you ...

Allow multiple inheritance from classes

If you inherit from a class in the framework or another third party library it would be great, if I could add stateful methods and properties - not extension methods. The easiest way would be multi inheritance. C++ can do so, so C# should allow this too. To add a simple Method for logging you have to write code over and over again.

one word: Perfect
this idea have a lot of advantages.
i don't explain all reasons, but recommend read Meyer's book: Object-Oriented Software Construction. In this book describe this feature in details.
Please allow it.

Isn't there another option we can think of instead of Yes or no multiple inheritance?

Is not an idea to have a feature that will allow you to extend a class with another class that has implementation of similar methods or that you wish to add (Not expose!) and can only be done if the target and source class implement both the same specific base class/interface.
Think a bit of the partial feature but then to allow extending a class.

// This class implements features of the interface and has extra methods that can be used when desired, but cannot be accessed outside of this class or the class that will extend this class.
public extending class Bar : IBarInterface {
public void Execute(){ ... }
public void Cancel() { ... }
public void AssistMethod() { ... }
}

// A class that is forced to use an already existing BaseFoo but we want to use the common implemented Bar for most things and because both have IBarInterface that is possible.
// Furthermore Execute is not needed to be implemented because Bar already has it implemented. (If would be extended by more that 1 class with that same signature it would be required again!)
public class Foo : BaseFoo, IBarInterface
with : Bar
{
// Own implementation of cancel in Foo
public void Cancel()
{
// Calling the extending class to invoke its Cancel
with.Cancel()
}

public void FooMethod()
{
// AssistMethod is not in the interface and needs to be wrapped if desired to expose to outside.
with.AssistMethod()
}
}

In this case the class Foo can be extended with basic features of Bar because it implements IBarInterface and Bar implements a default implementation for it.
With the 'with',like 'base' for extending classes, you can call a method of the class that you wish to use to extend the class with, but you cannot call from an instance Foo.
Thus new Foo().AssistMethod() is not possible unless the class Foo and Bar implements an interface for that.

It can even have multiple classes like this maybe.
public class Foo : BaseFoo, IBarInterface
with : Bar, Bar2
{
public void Cancel()
{
with.Cancel()
}

public void FooMethod()
{
with[Bar2].AssistMethod()
}
}

Of course not a proper proposal or such, but the whole stuck on multiple inheritance is not good, neither is not accepting it has a few good uses as well if we can avoid the multiple inheritance nonsense.

I want to add another comment about those opposed. The arguments from those opposed is based upon NOT allowing others something they disagree with. Adding Multiple Inheritance (MI), isn't going to force anyone to have to use it. But right now, the overhead in maintaince and loack of re-useability, if forced upon everyone.

MI should be added, it is a huge code-maintenance and code-re-useability enhancer that is optional to use. Any argument to say "Don't allow it", is frankly along the lines of envy/hate, no matter what arguments they use to justify their case.

The lack of multiple inheritance in C# has caused me "maintenance related grief" for over 10 years. And worse, the substitue of interfaces, has even further exasperated maintenance. And when I say maintenance, I do not mean code-reuseability, I mean, just have another person come in, and pick up the pieces from where one left off. And then of course, there is the exapseration from code not being as re-useable as possible.

Allowing multiple inheritance to ease the composition (and only for this) would be very useful. If a class implements two interfaces, and you have a sample class for both implementations, inheriting from these two classes that don't overlap should be perfectly fine.
If classes A and B share the same member or if some diamond graph is created (the common pitfalls of multiple inheritance), just throw a compiler error.

Please don't, not because it's inherently bad (no pun intended). But because there is much better ways to use VS developers time. You can use composition or interfaces, no cases require multiple inheritance.

> I would hightly recommand you to uses interface instead and for code sharing purpose create a class with static functions that you call from the implementation of your interface.

I'm working on a C# Android project, where i have to override again and again an OnSaveInstanceState method. The base classe changes often, and there is no common base class for special Activities and Fragments in the Android Mono Framework. So including the functionality in a base class and inheriting from it is not the good solution.

Composition does not work here also, as you still have to implement the method again and again, plus make sure the composed object is still live after restoration from tombstoning.

The only way that would work is inheriting an xxxImpl class, which would add the functionality.

Of course the problem here is because the Android Framework is badly written, or at least not written with C# in mind. But C# should allow such feature in order to fix this kind of framework.

I have a simple class that implements INotifyPropertyChanged, caches PropertyChangedEventArgs instances, and exposes PropertyChanged that you want to use the += operator on. I want to be able to tack this onto any other class. Without multiple inheritance I have to duplicate this functionality every single time and maintain it separately every single spot.

People who are against multiple inheritance tend to be simple programmers. Bleeding edge requires more.

I agree. Implement it as programmers we should be given the choice of usage. Anyone good enough to use multiple inheritance or one or more of its alternates, has enough knowledge to use it wisely or will learn how to in good time. Anyway, many companies will have their own programming policies which may or may not prevent or require programmers to use it or not. But esentially, let it be up to the programmer or company instead of it being a choice made for us.

It could save an awful lot of work. While there are many wonderful things about C#, for me I particularly like the static typing, the power of its its type system is still weak compared with Smalltalk and Lisp, both of which are much older languages. Bertrand Meyer is a great example of someone who values multiple inheritance but is no fan of C++.

I've yet to see a convincing argument against multiple inheritance. After all arguments have been debunked people always default to "but dumb programmers will abuse it!"

For example, the so called diamond problem is not a problem at all if you use something called "The Compiler" (tm). It should just throw an error if there's a collision and you don't specify which implementation of the method/property you want. That's it!

I don't see anyone complaining about the following line of code:
var monkey = isMonkey ? "y" : "n";

I just read about how other languages solve this problem after following your link and I think the way Python implements it is pretty intuitive.
Why should there be no such feature in C#? The risks of managing redundant code in multiple classes is far higher than the risks of encountering exceptions, at least in my opinion.
I could understand if people don't want this to be supported in Basic, as it is usually used to get comfortable with programming basics, but C# is more "professional" in some way. Professionals should be able to handle this feature and resolve problems when encountering them. Also, nobody would be forced to us it.