I would like to proposed the following specification for Mixins be included as part of Version 1.0
D Programming Language specification. All comments are welcomed.
 
MIXINS SPECIFICATION      Version 0.1
 
Introduction
What are mixins ?
A mixin is a class-like entity whose methods/fields are mixed-in to the mixing class just
as if the author of that class had written them manually.
As Matthew so neatly put it (see http://www.digitalmars.com/drn-bin/wwwnews?D/28348 )
Why do we need them ?
The rational for Mixins is quite compelling...
One of the greatest shortcomings of the C++ language from a Object Oriented perspective,
is that there is no language support for Aggregated Objects. As such, Aggregation has to be
performed programatically, often (incorrectly) using the inheritance mechanism as a coding 
shortcut. By including language support we provide a direct correlation between OOD using
modeling techniques like UML, and OOP.
 
Background
Please read the following;
http://www.digitalmars.com/drn-bin/wwwnews?D/28455
http://www.digitalmars.com/drn-bin/wwwnews?D/28511
http://www.digitalmars.com/drn-bin/wwwnews?D/28553
 
Lexical
I propose that we use one of the two remaining (common) symbols, i.e. # and @ as well as
the keyword mixin. For this document we'll use # as the mixin symbol
 
Syntax
There are a number of syntax alternatives that could be incorporated.
 
Alternative A:
class <identifier> [: <inherited-class>]
                   [# <aggregated-class> <local-identifier>]*
 
For example;
class Lamp : Light
           # Body      cBody       
           # Switch    cSwitch
           # Globe     cGlobe
           # PowerCord cPowerCord
{
    this() {
        super();                    
        cBody();                     // Body construction
        cGlobe();                    // Globe construction
        cPowerCord();                // PowerCord construction
        cSwitch(cGlobe,cPowerCord);  // Switch construction
    }
};
 
Alternative B:
class <identifier> [: <inherited-class>]
                   [# <aggregated-class> <local-identifier>
                   [, <aggregated-class> <local-identifier>]*]
 
For example;
 
class Lamp : Light
           # Body      cBody 
           , Switch    cSwitch
           , Globe     cGlobe
           , PowerCord cPowerCord
{
    this() {
        super();
        cBody();                     // Body construction
        cGlobe();                    // Globe construction
        cPowerCord();                // PowerCord construction
        cSwitch(cGlobe,cPowerCord);  // Switch construction
    }
};
 
Semantics
The rules for Mixin variables should be the same as class member declarations, except
Mixins allow the interfaces of the aggregated class to be included as part of the mixing class.
This fact means that it is possible to have multiple versions of the same member name
within a mixing class.
 
I propose a simple precedence rule, where the member defined in the class overrides those
defined in the aggregated class, and those in the aggregated classes are assigned according
to the order they are declared. If this was to take place, a compiler warning message stating
"that member X of aggregated class A is taking precedence over that in aggregated class B"
should be displayed in the error log.
 
Note: there are probably other things that will need to be considered here !
 
Conclusion
Mixins permit externally declare classes to be used as part of a class, and in so doing provides
a real alternative to the Multiple Inheritance option provided for in the C++ language. As such, this
relatively insignificant addition to the language should greatly enhance the overall flexibility of the
D Programming Language. 
 
Comments !