Quote from: http://www.digitalmars.com/d/mixin.html
> Unlike a template instantiation, a template mixin's body is evaluated
within the
> scope where the mixin appears, not where the template declaration is
defined.
> It is analogous to cutting and pasting the body of the template into the
location
> of the mixin.

In my view it would be realy nice to allow the following code:

template Foo(){
    return:
	}

void doFoo(){
    mixin Foo;
}

Ok, that's a trival excample but should give you the idea.

The content of the version expression should only be interpreted after validating the scope of "version". e.g.

if( version(STRICT){a<200 || } a>0){
    // blabla
}

Thomas Kuehne wrote:

<snip>
> In my view it would be realy nice to allow the following code:
> 
> template Foo(){
>     return:
> 	}
> 
> void doFoo(){
>     mixin Foo;
> }
> 
> Ok, that's a trival excample but should give you the idea.
> 
> The content of the version expression should only be interpreted
> after validating the scope of "version". e.g.
> 
> if( version(STRICT){a<200 || } a>0){
>     // blabla
> }

Both those features smack of textual processing to me.

"Modern languages should not be text processing, they should be symbolic processing."

And a potential parsing nightmare.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ce2col$ikr$1@digitaldaemon.com>,
 "Thomas Kuehne" <eisvogel@users.sourceforge.net> wrote:

> Quote from: http://www.digitalmars.com/d/mixin.html
> > Unlike a template instantiation, a template mixin's body is evaluated
> within the
> > scope where the mixin appears, not where the template declaration is
> defined.
> > It is analogous to cutting and pasting the body of the template into the
> location
> > of the mixin.
> 
> In my view it would be realy nice to allow the following code:
> 
> template Foo(){
>     return:
> 	}
> 
> void doFoo(){
>     mixin Foo;
> }
> 
> Ok, that's a trival excample but should give you the idea.
> 
> The content of the version expression should only be interpreted after validating the scope of "version". e.g.
> 
> if( version(STRICT){a<200 || } a>0){
>     // blabla
> }



While I think versions should allow for expressions in the version condition and version identifiers be integers you could compare against. I don't really think that's necessarily something you should want to be doing with a version.  Although it should be allowed..

Stewart Gordon wrote:
> > In my view it would be realy nice to allow the following code:
> >
> > template Foo(){
> >     return:
> > }
> >
> > void doFoo(){
> >     mixin Foo;
> > }
> >
> > Ok, that's a trival excample but should give you the idea.
> >
> > The content of the version expression should only be interpreted after validating the scope of "version". e.g.
> >
> > if( version(STRICT){a<200 || } a>0){
> >     // blabla
> > }
>
> Both those features smack of textual processing to me.
>
> "Modern languages should not be text processing, they should be symbolic processing."
>
> And a potential parsing nightmare.

They might sound like nightmare to you :)
I'll try to explain the situation I am currently in:

situation:
An complex if/else block: aprox. 30 different cases, maximum depth 4. While
the case handling is always the same the conditions for those cases differ
slightly depending on the "lax" or "strict" version.

solution 1:
Write 2 different functions both containing the same functionality but
slightly different case determination.
pro:
Compatible with current D. No extra computing costs(see solution 2).
contra:
difficult maintenance - risk to fix e.g. the "strict" but not the "lax"
version

solution 2:
Precalculate part of the if conditions before the actual "if".
pro:
Compatible with current D.
contra:
High computing cost of unrequired calculations.

solution 3.
Write code with Pre-processing through an external preprocessor.
pro:
easy maintenance; No extra computing costs(see solution 2).
contra:
incompatible with "plain" D.

Stewart, you are invited to present me a true "D" solution that is
a) easy to maintain and
b) has the best performance possible

Thomas

Thomas Kuehne wrote:

<snip>
> solution 3.
> Write code with Pre-processing through an external preprocessor.
> pro:
> easy maintenance; No extra computing costs(see solution 2).
> contra:
> incompatible with "plain" D.

What you're effectively doing is turning version into a preprocessor.

> Stewart, you are invited to present me a true "D" solution that is
> a) easy to maintain and
> b) has the best performance possible

Possibility 1: Assuming a is of type int, then

    version (STRICT) {
        const int UPPER = 200;
    } else {
        const int UPPER = int.min;
    }

    if (a < upper || a > 0) { ... }

Possibility 2:

    version (STRICT) {
        if (a < 200 || a > 0) doStuff();
    } else {
        if (a > 0) doStuff();
    }

where doStuff would typicaly be a nested function.  Presumably the compiler would inline it.

Possibility 3: realise that your disjunction of conditions is tautologically true, and simplify it to

    version (STRICT) {
        const int LOWER = 1;
    } else {
        const int LOWER = int.min;
    }

    if (a >= lower) { ... }

or

    version (STRICT) {
        doStuff();
    } else {
        if (a > 0) doStuff();
    }

Possible idea for D improvement: to invent a VersionExpression, enabling stuff like

    if (version(STRICT) ? true : (a > 0)) { ... }

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

<snip>
>     version (STRICT) {
>         const int UPPER = 200;
>     } else {
>         const int UPPER = int.min;
>     }
> 
>     if (a < upper || a > 0) { ... }
<snip>

Oops ... NTS, that was meant to be

    if (a < UPPER || a > 0) { ... }

and similarly with the other instance.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Thomas Kuehne wrote:
> if( version(STRICT){a<200 || } a>0){
>     // blabla
> }

version (STRICT)
   const strict = 1;
else
   const strict = 0;

...

if ( (strict && a < 200) || a > 0)
{
    ...
}

Constant folding will take care of eliminating unneeded extra tests.