http://d.puremagic.com/issues/show_bug.cgi?id=1528

           Summary: shouldn't templates conflict with templates?
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: davidl@126.com


int[char] v;
char m;
int d;

template toString (U,C,T:U[C])
{
        char[] toString(U m,C c, T t) { return ""; }
}
char[] toString(int k){return "";}

The confliction can actually be detected till the last moment of instantiation. I don't see why we prevent it at the moment.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1528


wbaxter@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|shouldn't templates conflict|templates should not
                   |with templates?             |conflict with non-templates




------- Comment #1 from wbaxter@gmail.com  2007-09-22 22:17 -------
The ability to do this sort of overloading is scheduled to be added to D2.0, according to the notes from the Walter/Andrei talk at the D conference.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1528


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|spec                        |
                 CC|                            |clugdbug@yahoo.com.au
           Severity|trivial                     |enhancement


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #2 from yebblies <yebblies@gmail.com> 2011-12-25 03:32:10 EST ---
*** Issue 7134 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
                 CC|                            |yebblies@gmail.com
           Platform|x86                         |All
            Summary|[tdpl] templates should not |[tdpl] overloading template
                   |conflict with non-templates |and non-template functions
         OS/Version|Windows                     |All
           Severity|enhancement                 |major


--- Comment #3 from yebblies <yebblies@gmail.com> 2011-12-25 03:37:21 EST ---
From Andrei's comment in 7134:

This TDPL code does not compile:

class A {
   // Non-overridable method
   A opBinary(string op)(A rhs) {
      // Forward to an overridable function
      return opBinary(op, rhs);
   }
   // Overridable method, dispatch string at runtime
   A opBinary(string op, A rhs) {
      switch (op) {
         case "+":
            break;
         case "-":
            break;
      }
   }
}

Overloading template and non-template functions must be implemented.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528



--- Comment #4 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-12-24 09:15:52 PST ---
Thanks for consolidating!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha@yahoo.com


--- Comment #5 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-01-21 18:22:11 PST ---
*** Issue 2972 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528


Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras@gmail.com


--- Comment #6 from Simen Kjaeraas <simen.kjaras@gmail.com> 2012-08-25 05:53:56 PDT ---
This bug causes problems with @disabled default constructors.

Given:

struct Foo {
    @disable this();
    this( T )( T a ) {
    }
}

This bug triggers.

Given instead:

struct Bar {
    @disable this( )( );
    this( T )( T a ) {
    }
}

The default constructor is not disabled.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-08-25 11:18:39 PDT ---
> This bug causes problems with @disabled default constructors.

From what I can tell, @disable this() doesn't work _at all_: bug# 7021

I don't think that this bug has anything to do with it.

And I wouldn't expect @disable this()(); to work anyway, because the function
that you're trying to disable doesn't exist. It would have to be instantiatied
to exist, and it's not possible to call a default constructor on a struct,
since they're not legal in the first place, so it can't be instantiated.
@disable this()(); should probably result in an error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1528



--- Comment #8 from Simen Kjaeraas <simen.kjaras@gmail.com> 2012-08-25 12:19:25 PDT ---
(In reply to comment #7)
> > This bug causes problems with @disabled default constructors.
> 
> From what I can tell, @disable this() doesn't work _at all_: bug# 7021

@disable this() does work in some cases:

struct Foo {
    @disable this( );
}

struct Bar {
    Foo f;
    this( int n ) {
        // Error: constructor Bar.this field f must be initialized in
constructor
    }
}

void main( ) {
    Foo f; // Error: variable main.d initializer required for type Foo
}

However, if you need a templated constructor, this goes out the window, for the reasons outlined above.


> I don't think that this bug has anything to do with it.

Yes and no. The problems of @disable this are exacerbated by this bug.


> And I wouldn't expect @disable this()(); to work anyway, because the function
> that you're trying to disable doesn't exist. It would have to be instantiatied
> to exist, and it's not possible to call a default constructor on a struct,
> since they're not legal in the first place, so it can't be instantiated.
> @disable this()(); should probably result in an error.

Nor would I, but when faced with the error that templated and non-templated functions cannot form an overload set together, that is the logical thing to try, and it doesn't work either.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------