Recursive aliases?

[Timon Gehr]

On 04/23/2012 01:44 PM, Steven Schveighoffer wrote:
> On Sat, 21 Apr 2012 15:46:29 -0400, Mehrdad <wfunction at hotmail.com> wrote:
>
>> alias int delegate(out ItemGetter next) ItemGetter;
>>
>> We currently can't do the above^ in D, but what do people think about
>> allowing it?
>> i.e. More specifically, I think an alias expression should be able to
>> refer to the identifier (unless it doesn't make sense, like including
>> a struct inside itself).
>> (It would require a look-ahead.)
>
> It doesn't work.
>
> If I do this:
>
> alias int delegate() dtype;
>
> alias int delegate(dtype d) ddtype;
>
> pragma(msg, ddtype.stringof);
>
> I get:
>
> int delegate(int delegate() d)
>
> Note how it's not:
>
> int delegate(dtype d)
>
> Why? Because alias does not create a new type. It's a new symbol that
> *links* to the defined type.
>
> How shall the compiler expand your example so it can know the type?

Basically the same way it detects recursive aliases. It is not really an 
implementation problem, but it would add a special case (don't expand 
recursive aliases). In general, it would get a little bit challenging to 
resolve recursive types in a reliable way:

typeof(dg) delegate(typeof(dg(dg)(dg)), typeof(dg(dg)) = 
typeof(dg(dg(dg))).init) dg; // type safe!

Implementing those infinite types would be a fun exercise though :o)

> It works for classes because classes are a new type which do not need to
> have another type backing it.
>
> The solution? Well, there are two possible ones. One is you create a
> ficticious type (or use void *) and cast when inside the delegate. The
> other is to not use delegates, but use types instead. Either a struct or
> a class/interface will do, something for the compiler to anchor on.
>
> -Steve

Sure, but it shouldn't be necessary. There is no reason why it could not 
work except for the added complexity.