Could you change it so that expressions, that are separated by commas and inside an if-clause, would have visibility to the variable defined in the first expression? Easier to show than to explain:

int getInt()
{
    return 11;
}

void main()
{
    if (int n = getInt(), n > 10) // undefined identifier n
    {
        //...
    }

    if (int n = getInt(), ++n, n > 10) // undefined identifier n
    {
        //...
    }

    if (int n = getInt(), getInt() > 10) // OK
    {
        //...
    }
}

That would make it possible to define variables in the smallest possible scope, and not pollute the namespace of the enclosing scope.

On Thursday, 4 October 2012 at 21:17:51 UTC, Tommi wrote:
> Could you change it so that expressions, that are separated by commas and inside an if-clause, would have visibility to the variable defined in the first expression? Easier to show than to explain:
> [SNIP]

A language change sounds excessive for something that simple blocks could fix:

int getInt()
{
    return 11;
}

void main()
{
    {
        int n = getInt();
        if (n > 10) // OK
        {
            //...
        }
    }
    {
        int n = getInt(); ++n;
        if (n > 10) // OK
        {
            //...
        }
    }
    {
        int n = getInt();
        if (getInt() > 10) // OK
        {
            //...
        }
    }
}

Been doing this in C++ for a while actually.

On Thursday, October 04, 2012 23:11:58 Tommi wrote:
> Could you change it so that expressions, that are separated by commas and inside an if-clause, would have visibility to the variable defined in the first expression? Easier to show than to explain:
> 
> int getInt()
> {
> return 11;
> }
> 
> void main()
> {
> if (int n = getInt(), n > 10) // undefined identifier n
> {
> //...
> }
> 
> if (int n = getInt(), ++n, n > 10) // undefined identifier n
> {
> //...
> }
> 
> if (int n = getInt(), getInt() > 10) // OK
> {
> //...
> }
> }
> 
> That would make it possible to define variables in the smallest possible scope, and not pollute the namespace of the enclosing scope.

If you want to restrict the scope of a variable, you can simply use another set of braces to create a new scope. It might be more verbose than desirable, but it works just fine. e.g.

{
 int n = getInt();
 if(n > 10)
 {
 ...
 }
}

As it stands, there's a good chance that the comma operator is actually going to be _removed_ from the language (aside from specific use cases such as inside for loops). So, I don't think that there's much chance of it being expanded at all.

- Jonathan M Davis

On Thursday, 4 October 2012 at 21:32:34 UTC, Jonathan M Davis wrote:
>
> If you want to restrict the scope of a variable, you can simply use another set of braces to create a new scope. It might be more verbose than desirable, but it works just fine. e.g.
>
> {
>  int n = getInt();
>  if(n > 10)
>  {
>  ...
>  }
> }

But if there are else-if clauses, then you end up polluting your namespace, and notice how the syntax of your workaround deteriorates exponentially:

The extended if-clause syntax:
------------------------------

if (byte n = fun1(), n > 10)
{
    //...
}
else if (int n = fun2(), n > 100)
{
    //...
}
else if (ulong n = fun3(), n > 1000)
{
    //...
}


The workaround syntax:
----------------------

{
    byte n1 = fun1();
    if (n1 > 10)
    {
        //...
    }
    else
    {
        int n2 = fun2();
        if (n2 > 100)
        {
            //...
        }
        else
        {
            ulong n3 = fun3();
            if (n3 > 1000)
            {
                //...
            }
        }
    }
}


> As it stands, there's a good chance that the comma operator is actually going to be _removed_ from the language (aside from specific use cases such as inside for loops). So, I don't think
> that there's much chance of it being expanded at all.

I don't see a problem there. I mean, if the comma operator is kept in specific cases like inside for loop, why not keep (and expand it's use) it in this specific case of if-clause.

On Thursday, 4 October 2012 at 21:17:51 UTC, Tommi wrote:
> Could you change it so that expressions, that are separated by commas and inside an if-clause, would have visibility to the variable defined in the first expression?

Yes, a language designed could make that choice. But not, it certainly won't be considered for D unless it can be shown that the change solves a real problem with the current syntax. And how often have you really encountered big syntactic headaches because of not having something like this available?

David

On Thursday, 4 October 2012 at 22:28:24 UTC, David Nadlinger wrote:
>
> Yes, a language designed could make that choice. But not, it certainly won't be considered for D unless it can be shown that the change solves a real problem with the current syntax.

But I'm not suggesting any kind of change in syntax. This syntax in D currently works (as long as expr2 is convertible to bool):

if (Type var = expr1, expr2)
{
    //...
}

What I'm suggesting is, I think, quite reasonable: make it so that 'var' is visible to 'expr2'.

On Thursday, 4 October 2012 at 22:28:24 UTC, David Nadlinger wrote:
> how often have you really encountered big syntactic headaches because of not having something like this available?

I do somewhat regularly. The if(auto x = y()) { use x } is pretty convenient but being limited only to the bool check is kinda weak.

On Thursday, 4 October 2012 at 22:36:47 UTC, Tommi wrote:
> But I'm not suggesting any kind of change in syntax. This syntax in D currently works (as long as expr2 is convertible to bool):
>
> if (Type var = expr1, expr2)
> {
>     //...
> }
>
> What I'm suggesting is, I think, quite reasonable: make it so that 'var' is visible to 'expr2'.

Uh... I was actually wrong. What that syntax really does is this:

if (Type var = cast(Type)expr2)
{
    //...
}

Didn't see that coming. But I think it might be a bug, because assignment expression has precedence over sequencing expression, that is, expressions separated by commas.

On Thursday, 4 October 2012 at 23:16:53 UTC, Tommi wrote:
>
> Didn't see that coming. But I think it might be a bug, because assignment expression has precedence over sequencing expression, that is, expressions separated by commas.

Although that's not an assignment expression, but a variable definition. I think the following should be a bug then (currently):

if (int val = 123, true)
{
    //...
}

Because the following is a bug:

int val = 123, true; // Error: no identifier for declarator int
                     // Error: semicolon expected, not 'true'

On Thursday, October 04, 2012 23:56:15 Tommi wrote:
> > As it stands, there's a good chance that the comma operator is actually going to be _removed_ from the language (aside from specific use cases such as inside for loops). So, I don't think that there's much chance of it being expanded at all.
> 
> I don't see a problem there. I mean, if the comma operator is kept in specific cases like inside for loop, why not keep (and expand it's use) it in this specific case of if-clause.

You will have a hard sell with _anything_ involving commas other than tuples. Most people consider anything like the comma operator to be evil (or at least very undesirable).

- Jonathan M Davis