Phango - questions

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Mon Nov 19 14:16:43 PST 2007


Walter Bright wrote:

> Bill Baxter wrote:
>> Asking for a feature where class package.Options.Options can be accessed
>> as just package.Options seems a decent idea at first -- the same trick
>> works for templates after all -- but I don't think it would pan out.
> 
> You're right, templates do that, but it's a risky feature because it's
> essentially a special case hack. Anytime you do something like that, it
> can have subtle, unintended consequences.
> 
> My dislike of it has been one of the motivators for changing the syntax:
> 
> template Foo(T)
> {
>      class Foo
>      {
> ...
>      }
> }
> 
> has become:
> 
> class Foo(T)
> {
>      ...
> }
> 
> where the hack is not necessary.

You could have made class Foo(T) {} a synonym for anonym template + class
declaration. Still there's the problem that you may sometimes want to
change the nested symbol type based on template parameters so the special
case trick is still needed:

template Sacrifice(int i) {
  static if (i == 666)
    class Virgin {}
  else
    class Goat {}
}

The c++ way would avoid the special case, but I guess the reason for static
if was that it's "easier". What can you do, templates are damn verbose a
language for doing functional stuff.. I personally don't like the static if
since it tends to add redundancy - you need to write the same alias/const
foo = blahblah several times. You could loan syntax from functional
languages, but it might be hard to accommodate to a C-like language.



More information about the Digitalmars-d mailing list