In article <d66774$21ks$1@digitaldaemon.com>, Kevin Bealer says...
>
>In article <d636va$2v71$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Thomas Kuehne" <thomas-dloop@kuehne.thisisspam.cn> wrote in message news:0lofl2-jd3.ln1@lnews.kuehne.cn...
>>> .123 doesn't support this but I see no reason why "static if" would be hard to implement. Just enhance the version/debug condition implementation a bit and you get the same features as as "static if".
>>
>>Yup, that's nearly all there is to it. What's interesting, though, it how it transforms template metaprogramming. C++ template metaprogramming was 'discovered' rather than designed, and as Bill Baxter's reference shows, it is very hard to use.
>
>Does this paragraph mean you can do metaprogamming with static if, or am I reading too much into this?
>
>Kevin

Sorry - I was vague; I meant can looping like the "factorial" case be done; but I think this was asked and answered in another post.

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:d66774$21ks$1@digitaldaemon.com...
> In article <d636va$2v71$1@digitaldaemon.com>, Walter says...
> >
> >
> >"Thomas Kuehne" <thomas-dloop@kuehne.thisisspam.cn> wrote in message news:0lofl2-jd3.ln1@lnews.kuehne.cn...
> >> .123 doesn't support this but I see no reason why "static if" would be hard to implement. Just enhance the version/debug condition implementation a bit and you get the same features as as "static if".
> >
> >Yup, that's nearly all there is to it. What's interesting, though, it how
it
> >transforms template metaprogramming. C++ template metaprogramming was 'discovered' rather than designed, and as Bill Baxter's reference shows,
it
> >is very hard to use.
>
> Does this paragraph mean you can do metaprogamming with static if, or am I reading too much into this?

I think static if is a good step in the right direction, but it is nowhere near sufficient to have metaprogramming the way I (and others) would like it to be.

YUCK;

I hate uppercase, personally.  I was glad to see D got rid of the preproccessor and that silly convention :P.

My distaste of uppercase probably comes from the fact that my father used nothing but it; there was not a thing I remember him writing or typing that was not in uppercase.  When I was young, I remember him hitting the "CAPS LOCK" key every time the computer started up.

It also reminds me of QuickBASIC, which isn't a good thing :P.

-[Unknown]


> Just a thought. Instead of using static, would using UPPERCASE for static keywords be easier on the eyes? A bit like a C preprocessor macro.
> 
> template Integer(int nbits)
> {
>     IF (nbits <= 8)
>        alias byte Integer;
>     ELSE IF (nbits <= 16)
>        alias short Integer;
>     ELSE IF (nbits <= 32)
>        alias int Integer;
>     ELSE IF (nbits <= 64)
>        alias long Integer;
>     ELSE
>        ASSERT(0);
> }
> 
> Walter wrote:
> 
>> "Bill Baxter" <Bill_member@pathlink.com> wrote in message
>> news:d5c1mu$640$1@digitaldaemon.com...
>>
>>> Yikes!  All that is, really, is just an if-else, but dressed up in C++
>>
>>
>> template
>>
>>> metaprogramming it takes about a page of code!  My thought is that if the
>>> language actually had first-class support for metaprogramming, then you
>>
>>
>> could
>>
>>> just do something like write a short metafunction that returns a type:
>>>
>>> metafun type integer(int numbits)
>>> {
>>> if (numbits<=sizeof(char)) return char;
>>> if (numbits<=sizeof(short)) return short;
>>> if (numbits<=sizeof(int)) return int;
>>> if (numbits<=sizeof(long)) return long;
>>> if (numbits<=sizeof(cent)) return cent;
>>>
>>> metathrow "Compiler error";
>>> }
>>
>>
>>
>> You've inspired me:
>>
>> template Integer(int nbits)
>> {
>>     static if (nbits <= 8)
>>        alias byte Integer;
>>     else static if (nbits <= 16)
>>        alias short Integer;
>>     else static if (nbits <= 32)
>>        alias int Integer;
>>     else static if (nbits <= 64)
>>        alias long Integer;
>>     else
>>        static assert(0);
>> }
>>
>> int main()
>> {
>>     Integer!(8) i ;
>>     Integer!(16) j ;
>>     Integer!(29) k ;
>>     Integer!(64) l ;
>>     printf("%d %d %d %d\n", i.sizeof, j.sizeof, k.sizeof, l.sizeof);
>>     return 0;
>> }
>>
>>

Walter wrote:
> "Burton Radons" <burton-radons@smocky.com> wrote in message
> news:d65uvo$1sv1$1@digitaldaemon.com...
> 
>>No, no, I mean that "static assert" was the wrong design because it
>>shows an inconsistency when extended to apply to more statements.  So it
>>should be "const assert" as well as "const if" instead, while "static
>>assert" should be an error.
> 
> 
> "static assert" comes from C++ terminology for the same thing.

C++ sucks.

What about if you decide to add an attribute to functions which declare that they must be constant-folded if their parameters are constant, which allows the standard to declare exactly how much constant-folding is necessary for implementations.  What attribute do you use?  You can't use static, because it's already used with an entirely different meaning; however, static would be the consistent attribute.  This inconsistency is just setting up a problem which will take decades to sort out.

In article <d66uaa$2i1c$1@digitaldaemon.com>, Kevin Bealer says...
>>
>>Does this paragraph mean you can do metaprogamming with static if, or am I reading too much into this?
>
>Sorry - I was vague; I meant can looping like the "factorial" case be done; but I think this was asked and answered in another post.

No, it just replaces the standard method for "if" logic:

template If( bit eval, Then, Else ) {
alias Then If;
}

template If( bit eval : false, Then, Else ) {
aliass Else If;
}

If!( a < b, int, float ) x;

In article <d679mt$2ofi$1@digitaldaemon.com>, Burton Radons says...
>
>Walter wrote:
>> "Burton Radons" <burton-radons@smocky.com> wrote in message news:d65uvo$1sv1$1@digitaldaemon.com...
>> 
>>>No, no, I mean that "static assert" was the wrong design because it shows an inconsistency when extended to apply to more statements.  So it should be "const assert" as well as "const if" instead, while "static assert" should be an error.
>> 
>> 
>> "static assert" comes from C++ terminology for the same thing.
>
>C++ sucks.

I agree and very good point.

The use of static for both assert and if in this case is really non-intuitive and inconsistent with how it is used in other contexts (runtime evaluation). 'const' would seem to be better in both cases because they are evaluated strictly at compile time.

- Dave

>What about if you decide to add an attribute to functions which declare that they must be constant-folded if their parameters are constant, which allows the standard to declare exactly how much constant-folding is necessary for implementations.  What attribute do you use?  You can't use static, because it's already used with an entirely different meaning; however, static would be the consistent attribute.  This inconsistency is just setting up a problem which will take decades to sort out.

On Sun, 15 May 2005 06:52:55 -0400, Burton Radons <burton-radons@smocky.com> wrote:

> Walter wrote:
>> "Burton Radons" <burton-radons@smocky.com> wrote in message
>> news:d65uvo$1sv1$1@digitaldaemon.com...
>>
>>> No, no, I mean that "static assert" was the wrong design because it
>>> shows an inconsistency when extended to apply to more statements.  So it
>>> should be "const assert" as well as "const if" instead, while "static
>>> assert" should be an error.
>>   "static assert" comes from C++ terminology for the same thing.
>
> C++ sucks.
>
> What about if you decide to add an attribute to functions which declare that they must be constant-folded if their parameters are constant, which allows the standard to declare exactly how much constant-folding is necessary for implementations.  What attribute do you use?  You can't use static, because it's already used with an entirely different meaning; however, static would be the consistent attribute.  This inconsistency is just setting up a problem which will take decades to sort out.

Agreed.

Hey, that's a nifty start.

I see some folks are unhappy with the use of 'static'.  Is it too hard for the compiler to just figure out what is statically executable and avoid the use of the extra keyword altogether? Or is the thought that it's better for the programmer to have to declare their intent, so that e.g. the compiler can tell them it's impossible to do what they want at compile time.  At least it would be nice to be able to put it all in a block so you only have to type 'static' once.

>    static {
>      if (nbits <= 8)
>       alias byte Integer;
>      else if (nbits <= 16)
>       alias short Integer;
>      else if (nbits <= 32)
>       alias int Integer;
>      else if (nbits <= 64)
>       alias long Integer;
>      else
>       assert(0);
>     }

Hmm and why isn't it 'static else'?

Also, speaking of keywords sounding strange, it also seems kind of strange to call something like that a 'template', since it has little to do with the original meaning of the word.  Not that I really care, but it's sort of reminiscent of how C++ started off using the 'class' keyword for template type arguments, and eventually came around to using 'typename' instead.  I presume that was because it sounds nonsensical to pass in an 'int' as the 'class' parameter.

--bb

In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
>
>
>"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d5c1mu$640$1@digitaldaemon.com...
>> Yikes!  All that is, really, is just an if-else, but dressed up in C++
>template
>> metaprogramming it takes about a page of code!  My thought is that if the language actually had first-class support for metaprogramming, then you
>could
>> just do something like write a short metafunction that returns a type:
>>
>> metafun type integer(int numbits)
>> {
>> if (numbits<=sizeof(char)) return char;
>> if (numbits<=sizeof(short)) return short;
>> if (numbits<=sizeof(int)) return int;
>> if (numbits<=sizeof(long)) return long;
>> if (numbits<=sizeof(cent)) return cent;
>>
>> metathrow "Compiler error";
>> }
>
>You've inspired me:
>
>template Integer(int nbits)
>{
>    static if (nbits <= 8)
>       alias byte Integer;
>    else static if (nbits <= 16)
>       alias short Integer;
>    else static if (nbits <= 32)
>       alias int Integer;
>    else static if (nbits <= 64)
>       alias long Integer;
>    else
>       static assert(0);
>}
>
>int main()
>{
>    Integer!(8) i ;
>    Integer!(16) j ;
>    Integer!(29) k ;
>    Integer!(64) l ;
>    printf("%d %d %d %d\n", i.sizeof, j.sizeof, k.sizeof, l.sizeof);
>    return 0;
>}
>
>

Would static if support blocks such as...
static if (condition){...}
and if so, will everything in that block be considered static as well?

Also, are you considering a static switch?
I would think that should be almost as straight forward to implement as static if.

Any other static logic support planned, or contemplated?

TZ

"Burton Radons" <burton-radons@smocky.com> wrote in message news:d65uvo$1sv1$1@digitaldaemon.com...
> Walter wrote:
>
> > "Burton Radons" <burton-radons@smocky.com> wrote in message news:d65at9$1flf$1@digitaldaemon.com...
> >
> >>I think this is showing up a previous design error.  This use of static isn't logically consistent:
> >>
> >>     if (nbits <= 8)
> >>     static if (nbits <= 8)
> >>
> >>Versus:
> >>
> >>     int c = 4;
> >>     static int c = 4;
> >>
> >>So this should be "const" instead.  Rather than overloading the meaning of the keyword as is done with static, it would just be extending it to act a little more uniform.
> >
> >
> > I thought it would be consistent with the use of assert(exp) versus static
> > assert(exp).
>
> No, no, I mean that "static assert" was the wrong design because it shows an inconsistency when extended to apply to more statements.  So it should be "const assert" as well as "const if" instead, while "static assert" should be an error.

Different people, different opinions.  To me, "static if" fits the usage better than "const if" does... but that's just my opinion.

TZ