Question: Can we restrict the scope of internally declared our parameters?

[KorporalKernel]

I'm reading this article and it says

In Preview 4, the scope rules are more restrictive: Out variables are scoped to the statement they are declared in. Thus, the above example will not work until a later release.

However I was wondering if it is not preferable to retain greater scope restrictions. I'd like to a fragment like this:

if (TryGetSomething(someKey, out var something))
{
   // do stuff with something
}

something.x = true; 

to generate a compiler error for the last line, by making the declared "something" out of scope outside of the "if" block.

Why was this not done? If I want it to not be out of scope then I'd simply declare it before the "if" block.

[HaloFour]

Why was this not done? If I want it to not be out of scope then I'd simply declare it before the "if" block.

It was decided that by not having leaky scope severely limited the use cases in which the feature could be used. Big debate ensued. The language designers made their decision and that's what was implemented.

[HaloFour]

dotnet/roslyn#16640

[AustinBryan]

Jon Skeet said that it would be really annoying if you couldn't do something like this:

public void DoSomethingWithFoo()
{
    // return because the whole method depends on foo
    if (!TryGetSomething(someKey, out var foo)) return;   

    // do something with foo
}

And I totally agree. If the entire method depends on a conditonal (or even multiple ones, which tends to be the case when make Windows Forms) I prefer to check the opposite conditional and then return to save on indentation and lines.

public void DoBar()
{
    if (bar != null)
    {
        // Do bar stuff
    }
}

Isn't as clean as:

public void DoBar()
{
    if (bar == null) return;
    
    // Do bar stuff
}

In my opinion, so it would be annoying if I couldn't use out parameters in a similar fashion.

[KorporalKernel]

@AustinBryan - Jon's concerns are very reasonable, but I would have argued that the price is worth paying because one can always declare the variable in the old way and get what they want.

public void DoSomethingWithFoo()
{
    string foo;
    // return because the whole method depends on foo
    if (!TryGetSomething(someKey, out foo)) return;   

    // do something with foo
}

All that's been achieved is a small simplification in how we declare out parameters, imposing a more restrictive scope would have been extremely helpful and make it much easier to avoid NREs when using the Try... pattern - this is a missed opportunity IMHO.

[HaloFour]

@Korporal

Jon's concerns are very reasonable, but I would have argued that the price is worth paying because one can always declare the variable in the old way and get what they want.

That argument was made. It wasn't found compelling. You'll find a number of people on this repo who agree with your assessment and argued against this decision at the time. But at this point it's too late. The language has shipped with the "leaky" scope and to alter that would be a breaking change.

[CyrusNajmabadi]

@Korporal

but I would have argued that the price is worth paying

That was the exact position that was put forth and debated in-depth. At the end, the LDM (myself included) felt the price was not worth paying and we went with the direction you see now. It was made conscientiously and will full awareness of the concerns here.