www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8074] New: template-mixin example contradicts text

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074

           Summary: template-mixin example contradicts text
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: websites
        AssignedTo: nobody puremagic.com
        ReportedBy: tim.dolores gmail.com


--- Comment #0 from Tim Smith <tim.dolores gmail.com> 2012-05-09 09:52:31 PDT
---
The text says:

"If two different mixins are put in the same scope, and each define a
declaration with the same name, there is an ambiguity error when the
declaration is referenced"

However, the example *does* compile with no error, and runs the Bar.func()
method. Here is the exact code I'm using:

$ cat mix08.d
import std.stdio, std.exception;

/*
   If two different mixins are put in the same scope, and each define a
   declaration with the same name, there is an ambiguity error when the
   declaration is referenced:
 */

mixin template Foo() {
    int x = 5;
    void func(int x) { writeln("Foo.func(), x = ", x); }
}

mixin template Bar() {
    int x = 4;
    void func() { writeln("Bar.func(), x = ", x); }
}

mixin Foo;
mixin Bar;

void main() {
    //writefln("x = %d", x); // error, x is ambiguous
    /*
       The call to func() is ambiguous because Foo.func and Bar.func are in
       different scopes.
     */
    func();             // error, func is ambiguous
}

$ dmd|grep DMD
DMD64 D Compiler v2.059
$ dmd -w mix08.d
$ ./mix08
Bar.func(), x = 4
$ 


I don't know if the text is wrong, or if DMD is wrong.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 09 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074



--- Comment #1 from Tim Smith <tim.dolores gmail.com> 2012-05-09 09:54:19 PDT
---
I forgot to link to the exact spec page I'm talking about:

http://dlang.org/template-mixin.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei erdani.com,
                   |                            |andrej.mitrovich gmail.com


--- Comment #2 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-02-06
20:22:31 PST ---
I seriously doubt we could implement this now without breaking code. Chances
are people are using it to inject multiple function overloads.

I think we'll simply have to edit that part out of the website. Andrei do you
agree?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074



--- Comment #3 from Andrei Alexandrescu <andrei erdani.com> 2013-02-07 09:21:17
PST ---
We should fix this, it's clearly a crass error. We can't afford to arbitrarily
pick the last lexical declaration in case of an ambiguity.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074



--- Comment #4 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-02-07
09:53:20 PST ---
(In reply to comment #3)
 We should fix this, it's clearly a crass error. We can't afford to arbitrarily
 pick the last lexical declaration in case of an ambiguity.

But there is no ambiguity, the two functions are: void func(int x) { writeln("Foo.func(), x = ", x); } void func() { writeln("Bar.func(), x = ", x); } Neither of these can hijack one another. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074



--- Comment #5 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2013-02-07
09:54:00 PST ---
(In reply to comment #4)
 (In reply to comment #3)
 We should fix this, it's clearly a crass error. We can't afford to arbitrarily
 pick the last lexical declaration in case of an ambiguity.

But there is no ambiguity, the two functions are: void func(int x) { writeln("Foo.func(), x = ", x); } void func() { writeln("Bar.func(), x = ", x); } Neither of these can hijack one another.

Edit: Well except the case of taking the address of such a function which could prove problematic. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074



--- Comment #6 from Kenji Hara <k.hara.pg gmail.com> 2013-02-14 09:01:34 PST ---
I think there is no ambiguity for current behavior.

I can explain it based on the 'overload set resolution rule'.

Please regard these mixin declarations as two import statements.

  mixin Foo;
  mixin Bar;
  void main() { func(); }

Can be considered to:

  import foo;
  import bar;
  void main() { func(); }

And each module contains following declarations.

  module foo;  // ---
  int x = 5;
  void func(int x) { writeln("Foo.func(), x = ", x); }

  module bar;  // ---
  int x = 4;
  void func() { writeln("Bar.func(), x = ", x); }

Finally, the 'func()' is resolved to the call of bar.func.

"compiler will resolve an ambiguous mixin-ed symbol by regarding it as overload
set.." - This is much reasonable and consistent rule. If 'foo' is called with
some arguments but cannot eliminate the ambiguity, it will be error. Otherwise
simply will succeed to call.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 14 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8074


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu


--- Comment #7 from Martin Nowak <code dawg.eu> 2013-05-20 11:34:15 PDT ---
(In reply to comment #6)
 I can explain it based on the 'overload set resolution rule'.

Yes, according to http://dlang.org/template-mixin.html these form an overload set and only one of the sets has a match. (In reply to comment #5)
 Edit: Well except the case of taking the address of such a function which
could > prove problematic.

No problem here, you just have to specify the function type. void foo() {} void foo(int) {} void main() { void function() a1 = &foo; void function(int) a2 = &foo; auto b1 = cast(void function())&foo; auto b2 = cast(void function(int))&foo; assert(cast(void*)a1 !is cast(void*)a2); assert(a1 is b1); assert(a2 is b2); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 20 2013