typedef, why did it go? Is there anything instead?

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.742.1327344456.16222.digitalmars-d at puremagic.com...
> On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
>> On 1/23/2012 5:08 AM, Iain Buclaw wrote:
>> > Walter, what are your views on emitting the names of aliased types to
>> > debug?
>>
>> I don't really have an opinion on it, except that generally when I'm
>> debugging I'm interested in what a type really is, not the layer over it.

That's a pain in the ass for library users. For example, Goldie uses a lot 
of type sugar so that a nonteminal generated from the rule:

     <Foo> ::= <Bar> ';'

Is usually referred to as type:

     A: Token_myLang!("<Foo>", "<Bar>", ";")

Instead of:

     B: Token_myLang!(
        "<Foo>",
        Token_myLang!(SymbolType.NonTerminal, "<Bar>"),
        Token_myLang!(SymbolType.Terminal, ";") )

     or:

     C: _Token_myLang!("<Foo>", 47); // Rule ID#

The "B" is a rarely-needed unsugared version (which is guaranteed to be 
unambiguous with other symbols in th grammar). And "C" (or something similar 
to it) is the true underlying type that's intended purely as an 
implementation detail - *NOT* for user consumption.

The policy of showing types de-aliased breaks proper encapsulation and just 
detroys all of the above whenever there's a type error (which is the whole 
point of having those types in the first place).

>
> I usually want the aliased type.

Same here. I usually find it far more relevent to the code the compiler's 
referring too.

The current way is like having error messages show mangled names or talking 
in terms of the generated assembly instructions: It totally breaks out of 
the proper context and level-of-abstraction.

> I can look up what the alias is, but I can't
> know that something is using an alias if the alias is gone.
>

I hadn't thought of that, that's a good point, too.