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