"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:du8kgk$tem$1@digitaldaemon.com...
> I hadn't even thought of that yet...  and I love it!  A server project of mine uses the 'in' operator quite a bit, and I've always been annoyed with predeclaring variables and whatnot.  Now I won't have that issue, so long as Walter does the Right Thing (TM) and leaves this in.

It'll stay in, but it'll be in the form:

    if (auto p = key in AA)

as just about everyone seemed to prefer that syntax.

Walter Bright wrote:
> "Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:du8kgk$tem$1@digitaldaemon.com...
> 
>>I hadn't even thought of that yet...  and I love it!  A server project of mine uses the 'in' operator quite a bit, and I've always been annoyed with predeclaring variables and whatnot.  Now I won't have that issue, so long as Walter does the Right Thing (TM) and leaves this in.
> 
> 
> It'll stay in, but it'll be in the form:
> 
>     if (auto p = key in AA)
> 
> as just about everyone seemed to prefer that syntax. 
> 

Will this work:

if( auto a = something() && auto b = something())

a more general solution of declaring/initializing variables by parts of expressions?

(auto a1 = x*y-z) * (1 - (auto a2 = sin(x+y)))?

That would be a nice feature, but maybe too complicated and not that much used?

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dubrop$118j$1@digitaldaemon.com...
> Will this work:
>
> if( auto a = something() && auto b = something())
>
> a more general solution of declaring/initializing variables by parts of expressions?

No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario:

    if (auto a = foo() || auto b = bar())
    {
            a + b;        // is b declared or not?
    }

Walter Bright wrote:
> "Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dubrop$118j$1@digitaldaemon.com...
> 
>>Will this work:
>>
>>if( auto a = something() && auto b = something())
>>
>>a more general solution of declaring/initializing variables by parts of expressions?
> 
> 
> No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario:

OK, I get it.

> 
>     if (auto a = foo() || auto b = bar())
>     {
>             a + b;        // is b declared or not?
>     } 
> 
> 

On Mon, 6 Mar 2006, Walter Bright wrote:

> "Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:dubrop$118j$1@digitaldaemon.com...
> > Will this work:
> >
> > if( auto a = something() && auto b = something())
> >
> > a more general solution of declaring/initializing variables by parts of expressions?
> 
> No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario:
> 
>     if (auto a = foo() || auto b = bar())
>     {
>             a + b;        // is b declared or not?
>     }

Easy enough to define the behavior.  I'm not sure what an appropriate term is for variables declared like this, so insert something appropriate below.  Something like this would work reasonably well, probably:

   For all variables declared in an if expression, they will be default
initialized if their initializing expression is not executed due to short
circuit evaluation.

So..

    if (auto /* int */ res1 = someIntegerExpression() ||
        auto /* int */ res2 = someOtherIntegerExpression())
    {
        return res1 + res2;
    }

The results of that become well defined.  What would be potentially problematic is if return types are ever added to function overloading / resolution.  But I won't get into my opinions on that or on implicit typing as it's ornthogonal to this topic.

Later,
Brad

Brad Roberts wrote:
> 
>    For all variables declared in an if expression, they will be default initialized if their initializing expression is not executed due to short circuit evaluation.

I had the same thought.  But how much value is there in offering this feature?  Since D defaults to trap values when possible, the user should typically check all values that may have been default initialized before using them, and this seems to reduce the utility of this syntax.  Though I suppose this doesn't change the fact that there is a simple, valid solution to the problem, which is the point you were trying to make.


Sean

"Brad Roberts" <braddr@puremagic.com> wrote in message news:Pine.LNX.4.64.0603061143490.30259@bellevue.puremagic.com...
> Easy enough to define the behavior.

I know. But if there isn't an obvious and intuitive behavior to define, then one is picking something arbitrary. For example, the classic conundrum is:

    "12" + 6

Does that evaluate to "126" or 18? One can easilly define the behavior, but which one, and what will programmers expect it to be? With that expression, there really are only wrong answers, and so the only solution is to make it illegal.

For:

if (auto a = foo() || auto b = bar())
{
            a + b;        // is b declared or not?
 }

one could as sensibly define that b is only valid in the conditional subexpression in which it appears, as in:

if (auto a = foo() || (auto b = bar(), b + 1))    // ok, b valid in the b+1
expression
{
        a + b;  // error, b undefined here
}

Faced with two equally valid but incompatible definitions, I think the best course of action is to make it illegal, especially since there doesn't seem to be much utility in such a feature anyway.