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

           Summary: Add better Eponymous Template syntax is needed
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: verylonglogin.reg@gmail.com


--- Comment #0 from Denis <verylonglogin.reg@gmail.com> 2012-01-25 02:01:41 MSK ---
Current Eponymous Template syntax forces one to repeat a template name. It's
bad because:
* Templates often have long names like `FunctionTypeOf` (or longer) so it's
just long to write `alias <...> FunctionTypeOf;`.
* If one will make a misprint in retyping a long template name he will be
punished.
* If a template is renamed (can happened with private templates) or a part of
template is moved to an internal template every using of a template name should
be changed appropriately. If one will make a mistake in this renaming, see
previous case.

If, e.g. Alias This syntax will be added (with no more than one `alias this` per template), things will be significantly better because lots of Phobos (a real world library example) eponymous template aliases something. And now these templates look terrible. More than that, `this` is a keyword and will be highlighted in most editors unlike current syntax.


Inspired by "Aliasing of template results" post in NG by Alex Rønne Petersen.

-- 
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=7364


Nick Treleaven <ntrel-public@yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-public@yahoo.co.uk


--- Comment #1 from Nick Treleaven <ntrel-public@yahoo.co.uk> 2012-01-26 10:27:10 PST ---
Eponymous templates don't have to use 'alias', they can use an eponymous symbol like a variable or function. In these cases requiring an extra alias statement might not be desirable. So this request might not necessarily help all uses of eponymous templates.

-- 
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=7364


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

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


--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-01-26 10:31:36 PST ---
I believe that all of the examples in TDPL use enum rather than alias.

-- 
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=7364


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

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


--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-02-17 20:58:38 PST ---
Sample code to go with the request:

fullyQualifiedNameImplForTypes from std.traits is currently (excerpt from
code):

----
static if (is(T == string))
{
    enum fullyQualifiedNameImplForTypes = "string";
}
else static if (is(T == wstring))
{
    enum fullyQualifiedNameImplForTypes = "wstring";
}
else static if (is(T == dstring))
{
    enum fullyQualifiedNameImplForTypes = "dstring";
}
else static if (isBasicType!T || is(T == enum))
{
    enum fullyQualifiedNameImplForTypes = chain!((Unqual!T).stringof);
}
else static if (isAggregateType!T)
{
    enum fullyQualifiedNameImplForTypes =
chain!(fullyQualifiedNameImplForSymbols!T);
}
else static if (isStaticArray!T) { ... }
----

With an enhancement it could be turned into:

----
static if (is(T == string))
{
    enum this = "string";
}
else static if (is(T == wstring))
{
    enum this = "wstring";
}
else static if (is(T == dstring))
{
    enum this = "dstring";
}
else static if (isBasicType!T || is(T == enum))
{
    enum this = chain!((Unqual!T).stringof);
}
else static if (isAggregateType!T)
{
    enum this = chain!(fullyQualifiedNameImplForSymbols!T);
}
----

And for an alias example, current code:

----
template TransitiveBaseTypeTuple(T)
{
    static if (is(T == Object))
        alias TypeTuple!() TransitiveBaseTypeTuple;
    else
        alias TypeTuple!(BaseClassesTuple!T, InterfacesTuple!T)
            TransitiveBaseTypeTuple;
}
----

With the enhancement:

----
template TransitiveBaseTypeTuple(T)
{
    static if (is(T == Object))
        alias this = TypeTuple!();
    else
        alias this = TypeTuple!(BaseClassesTuple!T, InterfacesTuple!T);
}
----

The main benefit isn't less typing but less error-prone metaprogramming. It is very easy to introduce a typo in a template which doesn't instantly trigger a compile-time error. Even if it does result in a compile-time error it is hard to figure out what went wrong, for example:

----
template SomeEponymousTemplate(T)
{
    static if (is(T == int))
        alias SomeEponymousTemplate = int;
    else
        alias SomeEponymuosTemplate = float;  // note the typo
}

void main()
{
    alias Type = SomeEponymousTemplate!float;
    Type x;  // line 25
}
----

test(25): Error: template instance test.SomeEponymousTemplate!(float) is used
as a type

Note how the error appears when the type is used, not when the template is instantiated. I have had these instances of typos quote often in my metaprogramming code. I could resort to more vigorous copy-pasting, but this is a bad antipattern. Allowing 'this' in templates would be a an improvement.

I'd like to hear from our BDFL's, perhaps we'll get a pre-approved tag if they agree.

-- 
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=7364



--- Comment #4 from Nick Treleaven <ntrel-public@yahoo.co.uk> 2013-02-18 07:56:20 PST ---
Any solution should be able to replace the existing syntax completely, so the compiler would have to parse e.g. function template blocks:

template initOf(T)
{
    T this()
    {return T.init;}
}

I think instead of using 'this' for the symbol name, 'template' would be clearer.

-- 
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=7364



--- Comment #5 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-02-18 22:17:29 MSK ---
(In reply to comment #4)
> I think instead of using 'this' for the symbol name, 'template' would be clearer.

Agree.

-- 
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=7364



--- Comment #6 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-06-26 20:28:25 MSD ---
Original discussion: http://forum.dlang.org/thread/jfh7po$3b$1@digitalmars.com

-- 
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=7364


Tommi <tommitissari@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tommitissari@hotmail.com


--- Comment #7 from Tommi <tommitissari@hotmail.com> 2013-07-06 08:36:27 PDT ---
(In reply to comment #4)
> Any solution should be able to replace the existing syntax completely, so the compiler would have to parse e.g. function template blocks:
> 
> template initOf(T)
> {
>     T this()
>     {return T.init;}
> }
> 
> I think instead of using 'this' for the symbol name, 'template' would be clearer.

I think using 'out' as the symbol name would be even clearer. But I agree that 'template' is better than 'this'.

-- 
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=7364


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #8 from monarchdodra@gmail.com 2013-07-07 02:47:02 PDT ---
(In reply to comment #0)
> Current Eponymous Template syntax forces one to repeat a template name. It's
> bad because:
> * Templates often have long names like `FunctionTypeOf` (or longer) so it's
> just long to write `alias <...> FunctionTypeOf;`.
> * If one will make a misprint in retyping a long template name he will be
> punished.
> * If a template is renamed (can happened with private templates) or a part of
> template is moved to an internal template every using of a template name should
> be changed appropriately. If one will make a mistake in this renaming, see
> previous case.
> 
> If, e.g. Alias This syntax will be added (with no more than one `alias this`
> per template)

Just want to point out that technically, as long as you don't create any conflicts (eg functions that overload), then you can have as many eponymous entries as you wish.

template foo
{
    void foo(){}
    void foo(int i){}
}

> things will be significantly better because lots of Phobos (a
> real world library example) eponymous template aliases something. And now these
> templates look terrible. More than that, `this` is a keyword and will be
> highlighted in most editors unlike current syntax.
> 
> 
> Inspired by "Aliasing of template results" post in NG by Alex Rønne Petersen.

I have two problems with this.

1. The first is the the syntax `alias this` does not imply "shadowing" of the rest of the members. EG:

template Foo
{
    alias this = long;
    alias T = short;
}
//Later:
Foo a;
Foo.T b; //Error: T not a property of long ? What???

In this case, I think `alias this` does a bad parallel with *what* alias this actually does.

2. Ditto for functions:

template foo
{
    void this(){}
    void this(int i){}
}
//Template constructors?
//No! eponymous template!

Again, bad parralel between what "this" does in general case.

--------

So if I placed my vote on something, it would rather it be on the "template" keyword, or anything else actually. I'm not sold on using "this".

-- 
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=7364



--- Comment #9 from Nick Treleaven <ntrel-public@yahoo.co.uk> 2013-07-19 05:42:08 PDT ---
It might be easier to implement (particularly for templates resolving to functions) if we didn't reuse a keyword. Perhaps use __self:

template longNameWithSpecializations
{
    void __self(){...}
    void __self(int i){...}
}

The compiler can replace __self with the innermost template name. A nice side effect might be anonymous lambda recursion:

a => a > 2 ? a * __self(a - 1) : a

I think lambdas are implemented as templates, so the above feature might work naturally.

Eventually it would be nice if error messages used myTemplate.__self instead of myTemplate.myTemplate.

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