Bug 49 – Protection attributes of mixin instances are applied to a the wrong scope.

The following gives a compiler error (as in the comented line): template Baz() { private this() {} } class Foo { mixin Baz!(); // Error: .this is private }

Actually, this is part of the more general bug: Protection attributes of mixin instances are applied to the wrong scope. The following illustrates it: template Baz() { private void privfunc(){ } // private this() { } } class Foo { mixin Baz!(); void testfunc() { privfunc(); // Error: .privfunc is private } }

Actually, it isn't clearly defined. It states: "Unlike a template instantiation, a template mixin's body is evaluated within the scope where the mixin appears, not where the template declaration is defined." This leaves open the question of where it's access-checked. There was a discussion on this a while back: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/3101.html

(In reply to comment #2) > Actually, it isn't clearly defined. It states: > "Unlike a template instantiation, a template mixin's body is evaluated within > the scope where the mixin appears, not where the template declaration is > defined." > This leaves open the question of where it's access-checked. There was a > discussion on this a while back: > http://www.digitalmars.com/d/archives/digitalmars/D/bugs/3101.html In the very next sentenced it is said: "It is analogous to cutting and pasting the body of the template into the location of the mixin." which I think clears it up. Copy&Paste is the semantics I've been considering as the spec. (still, this doesn't say anything of whether this is or is not, the ideal language behavior.)

The key word is "analogous". Not "identical". The differences include several of those listed here: http://www.digitalmars.com/d/pretod.html#mixins Did you even begin to read the thread I just linked to? But even so, the testcases you have expose a different bug altogether, in which access to private members within a module isn't always honoured.

This one is outdated, updated to bug #471