Can we let while access variable in do scope?

[Thaina]

Whenever we want to do do{}while(); loop. Most of condition logic would actually use in this block, never gone out

So I think it would be more benefit if we could let while access variable in do block

Like this

do
{
    bool cond = false;
    // do work until cond = true
}
while(!cond);

So variable in the scope will be encapsulated only where it used. Not be seen outside

[alrz]

This is a breaking change since locals always take precedence over fields in binding.

[Thaina]

@alrz I think it about how we translate syntax into block

I mean, normally we always count only {} as being one block. What I propose is, are we able to extend scope of do{} block (and only for do keyword) to include while() until ; to be the same scope of above block instead

[alrz]

This is a working example that will break with this change:

bool cond; // field
void M() {
  do {
    string cond = "";

  } while( cond );
}

I'm not aware of any scoping rules that alter that precedence based on context.

[Thaina]

Thank you for enlighten me
OK so we might need new syntax for this

[jnm2]

I've long wondered why the while condition couldn't share scope with the body, but here we are. I don't think new syntax is better than moving the declaration of of the loop though.

Edit: scope not scoops. I have a really weird phone.

[Thaina]

@jnm2 For the concern that @alrz present I think we cannot directly extend scope out easily. But new syntax I said might be little tweak

Such as

do
{
    bool cond = false;
}for(!cond);

or maybe just

do
{
    bool cond = false;
}(!cond);

[jnm2]

I guess what I'm saying is, since the past is the past, rather than adding new syntax, what's so inconvenient about this:

bool cond;
do
{
    cond = false;
} while (!cond);

It's about as few words as it would be with new syntax anyway, and it doesn't complicate by adding new syntax.

If you really wanted to use the name cond in multiple loops, you'd do:

{ bool cond;
do
{
    cond = false;
} while (!cond); }

{ bool cond;
do
{
    cond = false;
} while (!cond); }

[Thaina]

@jnm2 Well I just confuse for what you saying a little. I didn't understand that you disagree. But that's ok. I just think what we currently did is dirty code (include what you present me). It should be compact and encapsulated. That's purpose of proposal

Same reason why we introduce foreach to iterate instead of just using Current and MoveNext() by ourself. Good syntax make things cleaner and better

[jnm2]

You make a good point. This isn't common enough in my code to justify adding language syntax, but others may have different experiences.

[jnm2]

I'd argue that if we keep the existing syntax, but include the loop condition in the scope of the body, if you do this:

private bool cond;

void Foo()
{
    do
    {
        bool cond = false;
    } while (!cond);
}

It would not be the worst thing in the world if the compiler gave an error that there is a conflict between cond and cond and didn't let you compile until you renamed or qualified this.cond. Yes, it's a breaking change, but the code was already awfully error-prone. This should be an extremely rare scenario.

[Thaina]

@jnm2

This isn't common enough in my code to justify adding language syntax

Normally I just do thing like this

//DoSomething n lines
while(!condition)
{
    //Copied of DoSomething n lines
}

or worse

while(!DoSomethingPassed(param))
{
}

bool DoSomethingPassed(param)
{
    //DoSomething n lines
    return cond;
}

or worst

while(true)
{
    //DoSomething n lines
    if(cond)
        break; // or return
}

Which is too dirty. Using do would be the best

[Thaina]

It would not be the worst thing in the world if the compiler gave an error that there is a conflict

Problem is it used to be valid code. So there could be in some codebase of some people in the world. And it would give error when they try to recompile it

Which is called breaking change

[jnm2]

Yes. Rather than complicate the syntax 99.99% of the time, I'd prefer we make the 0.01% people take a breaking change.

1. It's a safe breaking change- it does not silently change the way the program executes. Rather, it stops the program from compiling until they code it more clearly by using this.cond or renaming one of the identifiers.
2. They wrote confusing code which was a mistake waiting to happen and would probably be happy to fix it.

[Thaina]

@jnm2 I really want to agree with you but in the hat of proposer I need to take the safest route

[jnm2]

@Thaina Can we at least float both options? I see only benefits to the breaking change and it feels so much cleaner than adding syntax. /cc @CyrusNajmabadi

[CyrusNajmabadi]

1. We're certainly not going to take a breaking change here :)
2. I'm certainly sympathetic to the issue raised here. I routinely find myself with loops where i need to declare variables outside hte loop that are then only tested/accessed within the loop. So i know i would probably appreciate some language feature here.

That said, this seems like exceptionally marginal value. This would fall quite low on my list, and I'd far prefer we work on other stuff. Just my 2c here.

[jnm2]

Just to clarify, @CyrusNajmabadi, you're saying that if this language feature was top priority for C# 8.0 for whatever reason, you'd still prefer adding new syntax to the language over this type of breaking change, taking the points I outlined above into consideration? I'm interested in the general principle here.

[CyrusNajmabadi]

you're saying that if this language feature was top priority for C# 8.0 for whatever reason, you'd still prefer adding new syntax to the language over this type of breaking change,

Yes.

We are loath to make breaking changes. Generally, we only will if at a minimum all the following apply.

1. The benefits are staggeringly high.
2. The current approach is really bad.
3. The risk of breakage is very low.

Right now none of those even apply (let alone all three).

[iam3yal]

@CyrusNajmabadi, @jnm2, @Thaina There might be a place for repeat { } until (...) what do you think? :)

[jnm2]

I'm having syntax fatigue. Personally I'd prefer to put up with moving the declaration rather than think about two syntaxes.

[iam3yal]

@jnm2 Haha.. well, it's not new I mean if(...), switch(...), soon match(...). :)

[Thaina]

@CyrusNajmabadi would it counted as breaking change just tweak syntax like I was present?

do
{
    bool cond = false;
}(!cond); // why we need while here anyway? Legacy from C?
//or
do
{
    bool cond = false;
}for(!cond);

[CyrusNajmabadi]

That would not be a breaking change. But that doens't mean we'd take it. C# syntax has to feel adequately CSharpy. I'm not sure either of those apply. The first just looks like you forgot the while. The second just seems like some random change. if it's a for then why isn't it: do { ... } for (init; cond; incr) for example.

It's not sufficient to just be non-breaking-syntax. It also has to feel appropriate. To me, those don't fit the bill.

[Thaina]

@CyrusNajmabadi Thanks for your clarify. I just make sure I can hope for some way like that would not be breaking change

[wanton7]

How about this?

do (var cond = false)
{
  // do work until cond = true
} while (!cond)