www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7364] New: Add better Eponymous Template syntax is needed

reply d-bugmail puremagic.com writes:
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: -------
Jan 24 2012
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 07 2013
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jul 19 2013