Some posts ago a code segment brought up an issue regarding Mixins and protection attributes within them. Namely, if protection attributes of a mixin member will be applied to the mixin own (declaration) scope, or to the enclosing scope where the mixin is instantiated.
The code that illustrates this is:

  template Singleton(T)
  {
    private static T m_instance;
    public static this(){ m_instance = new T(); }
    public static T get(){ return m_instance; }
    private this(){}
  }

  class Foo
  {
    mixin Singleton!(Foo);
    // Error because Foo cannot access private Singleton.this()
  }

Currently the protection attributes are applied to the mixin own scope, and it wasn't clear then whether this is intended or is a bug. So, which is it?

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

In article <djj29j$14jf$1@digitaldaemon.com>, Bruno Medeiros says...
>
>Some posts ago a code segment brought up an issue regarding Mixins and protection attributes within them. Namely, if protection attributes of a mixin member will be applied to the mixin own (declaration) scope, or to the enclosing scope where the mixin is instantiated.

There is a related bug (?) that private data in templates is not visible to the outside world.  For example:

class C() {
private:
void fn() {}
}

C!().fn(); // fails to compile

This may be part of the current mixin problem.

Sean

Sean Kelly wrote:
> In article <djj29j$14jf$1@digitaldaemon.com>, Bruno Medeiros says...
> 
>>Some posts ago a code segment brought up an issue regarding Mixins and protection attributes within them. Namely, if protection attributes of a mixin member will be applied to the mixin own (declaration) scope, or to the enclosing scope where the mixin is instantiated.
> 
> 
> There is a related bug (?) that private data in templates is not visible to the
> outside world.  For example:
> 
> class C() {
> private:
> void fn() {}
> }
> 
> C!().fn(); // fails to compile
> 
> This may be part of the current mixin problem.
> 
> Sean
> 
> 

Your code is not valid. Perhaps you meant:

  templace C() {
  private:
    void fn() {}
  }

  C!().fn(); // fails to compile

? :p  If so, yes it seems to be quite the same problem, but is it a bug or intended? (or unexpected?)

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."