In article <d9gde9$1lls$1@digitaldaemon.com>, Walter says...
>
>
>"James McComb" <ned@jamesmccomb.id.au> wrote in message news:d9gc2f$1ica$1@digitaldaemon.com...
>> I accept both of these points, and they are probably enough to kill off the idea of using #. But are you averse to using other characters?
>>
>> For example, $:
>>
>> // S stands for static... $ kind of looks like S
>> $if() {}   // pronounced static if
>> $else() {} // pronounced static else
>>
>> (This might remind you of Perl, but I'm using $ on keywords, not variables. Other characters might be worth a look as well.)
>
>Using $ for various purposes has come up many times. (Currently it is an alternative to 'length' inside array indices.) Sometimes, @ gets proposed, but it looks too awful.
>
>Is static if that bad? Wouldn't using a syntax highlighting editor be a better solution?
>

I feel like a fish out of water trying to edit C# and such without a nice code editor. D changed that - Notepad works just fine for D. That's one of the things that makes D so comfortable.. IMHO, something along the lines of the idea above would be a worthy goal if it can be as quickly and simply implemented as the length symbol. It just makes for easier to read code IMO, because it is easier to distinguish than 'static' in plain old black and white.

- Dave

In article <opssujo0zy23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>My first thought was that # was a bad character to use (mental association with C/C++ pre-processor). That doesn't mean we can't use another character, or change the keywords themselves.
>
>I haven't tried to use static if at all really, but I agree a good IDE will be able to color it and make it stand out. D is designed to be easily parsable, for this exact reason.
>
>
>The epoch concept is interesting, I note 'static' currently appears in 2 epochs, compile and init. If we decide the epoch idea has merit then we need to fix that I reckon.

I think Derek cleaned this up neatly for both of us: things are either run-time or compile-time.  My use of "init time" was merely to draw distinction to the fact that 'static this' is technically a part of the runtime (code), but has a special place during the bootstrap of a program; hence that particular use of static has a special meaning.

- EricAnderton at yahoo

| Is static if that bad? Wouldn't using a syntax highlighting editor be a | better solution?

I have yet to encounter a IDE that can highlight "static if" differently from <static> <space> <if>.

Granted, I don't use many different IDEs, so there probably is one out there that can do it.

But what about the "else" appearing after the "static if { ...}"?  Must be some fancy highlighter to know it should be coloured 'statically'.. I guess this means that if "static" is changed into some prefix, it should also be applied to "else":

$version(x) {...} $else { ...}
#version(x) {...} #else { ...}

Or whatever. I truly hope we don't get another "what symbol is better" discussion. : S

L.

| What I would consider ideal, would be to have no visible distinction
between
| compile- and run-time code, letting the compiler figure out which
expressions
| are compile-time and not. For one reason or another, Walter chose not to
take
| this route.

Indeed! This makes perfect sense. Why do we even need a "static if"? I use "if(0)" a lot for skipping pieces of code during debugging, and I'll never write "statif if(0)", and shouldn't have to.

If the "is" (or other "operator") used inside the static if() has a different meaning because it's inside a static if, then maybe its name should be reconsidered instead. Or the "static" moved, ie if(static is....).

L.

IMHO, static if is more important not because it can't be determined, but because it proves it is determined.

It's just like type safety.  In scripting languages, one might say the compiler should be able to determine the type of the variable, for this example:

var x = 5;
x += 10;

Obviously it is an int.  Surely, we don't have to *TELL* the compiler that.  And, truth to tell, we don't - not in such simple cases.

But, sometimes it's good to be *sure*.  To know that this if is GOING TO BE STATIC.  And, if it's not - we'll get an error!  But, what about this:

var x = 5;
x += 10 ~ 1;

Oops.  Maybe in this imaginary (and dumb now) language, ~ might make 10 and 1 strings, and concatenate them - resulting in 'x+= "101"', which would result in "5101".  A typo on our part, but it's why we have typesafety, isn't it?

The same goes for static if.  It's type safety, at least imho.

-[Unknown]


> | What I would consider ideal, would be to have no visible distinction between
> | compile- and run-time code, letting the compiler figure out which expressions
> | are compile-time and not. For one reason or another, Walter chose not to take
> | this route.
> 
> Indeed! This makes perfect sense. Why do we even need a "static if"? I use "if(0)" a lot for skipping pieces of code during debugging, and I'll never write "statif if(0)", and shouldn't have to.
> 
> If the "is" (or other "operator") used inside the static if() has a different meaning because it's inside a static if, then maybe its name should be reconsidered instead. Or the "static" moved, ie if(static is....).
> 
> L. 
> 
> 

"Derek Parnell" <derek@psych.ward> wrote in message news:199skhy1f5i6n$.tcqfukcs4a0a.dlg@40tude.net...
> So ... reading between the lines (as the actual question was not directly
> answered - (ever think of going in to politics?) ) it seems that you are
> saying ...
>
> (A) There are many worth, competing goals for D and you have prioritized
> them.
> (B) You will not be doing anything to achieve this particular goal in the
D
> language.
> (C) You recommend using another tool to achieve it instead.

I would add to that that 'static if' is not that bad.

> I would like to point out that syntax highlighting does not work so well with commonly printed forms of source code. Color printing of source code is not yet economical enough for common use either in the work place or in published hard-copy works. Most code reviewing is done using printed (hard-copy) source code listings.

I know. One can still use boldface, fonts, etc., even with b/w hardcopy.

But I also suggest that one can use whitespace formatting and layout to emphasize or de-emphasize various aspects of the source code.

"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d9h6oj$2q2b$1@digitaldaemon.com...
> Indeed! This makes perfect sense. Why do we even need a "static if"? I use
> "if(0)" a lot for skipping pieces of code during debugging, and I'll never
> write "statif if(0)", and shouldn't have to.

That indeed was my original thought with this. Unfortunately, some limitations are:

1) if (0) introduces a new scope, static if(...) does not. Why does this
matter? It matters if one wants to conditionally declare a new variable:

    static if (...) int x; else long x;
    x = 3;

whereas:

    if (...) int x; else long x;
    x = 3;    // error, x is not defined

2) False static if conditionals don't have to semantically work. For example, it may depend on a conditionally compiled declaration somewhere else:

    static if (...) int x;
    int test()
    {
        static if (...) return x;
        else return 0;
    }

3) Static if's can appear where only declarations are allowed:

    class Foo
    {
            static if (...)
                int x;
    }

4) Static if's can declare new type aliases:

    static if (0 || is(int T)) T x;

On Fri, 24 Jun 2005 17:48:38 +0300, Lionello Lunesu <lio@lunesu.removethis.com> wrote:
> | Is static if that bad? Wouldn't using a syntax highlighting editor be a
> | better solution?
>
> I have yet to encounter a IDE that can highlight "static if" differently
> from <static> <space> <if>.
>
> Granted, I don't use many different IDEs, so there probably is one out there that can do it.

Derek found one:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/25749

> But what about the "else" appearing after the "static if { ...}"?  Must be some fancy highlighter to know it should be coloured 'statically'..

That's a good point.

> I guess
> this means that if "static" is changed into some prefix, it should also be applied to "else":
>
> $version(x) {...} $else { ...}
> #version(x) {...} #else { ...}
>
> Or whatever. I truly hope we don't get another "what symbol is better"
> discussion. : S

Those are never productive.

Regan

That explains a lot.. Thank you for the reply..

L.

Unknown W. Brackets wrote:
> Personally, I don't like this.  Specifically because the minute this changes, people will start:
> 
>   - complaining about #if enforcing scope.  C/C++ didn't require this, they'll say.
>   - aligning things to the far left like with a preprocessor, which is ugily.  I thought that was part of why D had these things in the language.
>   - asking for things like #ifdef instead of #version, and no parenthesis or curly braces.
> 
> Why?  Because you make it look like the preprocessor if you make this change.
<snip top of upside-down reply>

Taken the words out of my mouth there.  Making it look as though D has a preprocessor'll go against what we're trying to throw at D programmers.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.