www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2640] New: Improve usability of the "inner name trick"

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

           Summary: Improve usability of the "inner name trick"
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: andrei metalanguage.com


The "inner name trick" consists of a template only defining a symbol of the
same name as itself. Then, any instantiation of the template will in fact shunt
to the defined inner symbol. Example:

template A(T) { alias T[] A; }

Using e.g. A!(int) will be entirely synonymous with int[].

This is a hugely useful feature that is bound to be heavily used in a variety
of templated code. Unfortunately, there is a limitation - the template is
disallowed from defining any symbol. The motivation of the limitation is that
the shunting mechanism would in fact disallow access to that member.

The fallout of this is that many nontrivial templates follow the pattern:

template Widget(T)
{
    alias WidgetImpl!(T).Result Widget;
}

template WidgetImpl(T)
{
    ... actual implementation defining several private symbols ...
    alias ...something... Result;
}

That way users have the convenience of using Widget!(T) instead of
Widget!(T).Result, and the implementor has the ability to define nontrivial
template code that defines and uses several symbols towards computing the
desired result. The obvious cost is that extra code must be written.

I'd like to find a solution to this because the pattern is starting to creep
really bad in Phobos. One idea is to allow a template using the inner name
trick to define any number of symbols inside. As long as those symbols are
accessed USING UNQUALIFIED ACCESS, they are looked up normally. That means that
inside the template itself, defining "temporary" aliases is fair game. As soon
as the template is "closed", the user can't have access to the inner symbols.

Example:

template A(T) 
{
    alias T X;   // define inner symbol X
    alias X[] A; // use of UNQUALIFIED X ok
    alias A!(int).X Y; // error: type int[] does not define X
}

So, in short: the template can define and use symbols at its leisure. Use of
the symbols follow the normal rule: first in the template's scope, then
outside. But if the template aliases itself using the inner name trick, then
the shunting is done prior to looking the name up (as is done today).


-- 
Feb 01 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2640





------- Comment #1 from jarrett.billingsley gmail.com  2009-02-01 16:29 -------
Agreed 100%.  I think I even posted a suggestion to this effect years ago on
the digitalmars.D board?  I forget.


-- 
Feb 01 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2640





------- Comment #2 from 2korden gmail.com  2009-02-01 17:13 -------
Yeah, I have proposed that, too. I suggested marking all internal temporary
aliases as private for that purpose:

template WidgetImpl(T)
{
    private alias ...something_complex... Tmp; // not visible from outside
    alias ...something_else... WidgetImpl; // public
}


-- 
Feb 01 2009