Make initializer inside using scope

[ahdung]

Above codes actually is:

FolderBrowserDialog folderBrowserDialog = new FolderBrowserDialog();
folderBrowserDialog.ShowNewFolderButton = true;
folderBrowserDialog.Description         = Title;
folderBrowserDialog.SelectedPath        = InitialDirectory;
using (FolderBrowserDialog fbd = folderBrowserDialog)
{
    ...
}

So when folderBrowserDialog.ShowNewFolderButton = true; occurred exception, folderBrowserDialog will not be disposed. So for avoid this issue we have to abandon using object initializer:

using var fbd = new FolderBrowserDialog();
fbd.ShowNewFolderButton = true;
fbd.Description         = Title;
fbd.SelectedPath        = InitialDirectory;

which is no longer elegant, so please make initializer statement using-friendly.

Ref: https://dev.to/powerz/dangerous-using-declaration-c-80-3h86

[yaakov-h]

This belongs at https://github.com/dotnet/roslyn-analyzers/, however the analyzer is technically correct.

using var foo = new Foo { Bar = x() }; is translated by the compiler into:

var foo = new Foo();
foo.Bar = x();
using (foo) {

If foo.set_Bar or x() throw an exception then foo does not get disposed.

[HaloFour]

@ahdung

if SomeMethod throws, obj will not be created, nothing need dispose

If SomeMethod() throws, the reference created by new SomethingOrOther() has still created a disposable resource. You are correct in that it will not be assigned to obj, nor will the using statement apply to it. That is identical to initialization. The constructor has already been called and the resource allocated, but it has not been assigned to the using resource until after all initializers have completed. In both cases, a thrown exception will result in the allocated resource not being disposed.

[ahdung]

@CyrusNajmabadi Putting aside the debate over the definition of "finish", the point is using have responsibility for obj, as long as obj created, using need make sure to dispose it. The root of this problem is, initializer should happen after construction, but it been compiled to "before".

[ahdung]

@HaloFour

but it has not been assigned to the using resource until after all initializers have completed.

That's the problem is, so I asking for initializers should after assignment, the compiled code should equal with:

using var obj = xxx;
obj.XX = xxx;

This is in line with user’s intuitive expectations.

[HaloFour]

This is in line with user’s intuitive expectations.

This is not in line with how assignments have always worked in C#. The construction and initialization is a part of an expression which is independent of the assignment.

[CyrusNajmabadi]

The root of this problem is, initializer should happen after construction, but it been compiled to "before".

I disagree. Just with parameters, the execution happens prior. And if they throw, you won't have the completed object to dispose.

That's the problem is, so I asking for initializers should after assignment, the compiled code should equal with:

Strong disagree. That's not how initialization has ever worked. If we did that, we would now be able to observe things like:

this.Foo = new Foo
{
    X = ThrowSomething(),
}

Now the this.Foo field would be assigned, despite the throwing happening. Failure to initialize shouldn't end up allowing the value to leak out on the callsite.

[TahirAhmadov]

How about:

var folderBrowserDialog = using new FolderBrowserDialog
{
  ShowNewFolderButton = true,
  Description = Title,
  SelectedPath = InitialDirectory,
};

Here, using new is a new construct which requires an init block to follow the constructor call, and the above is translated to:

using var temp = new FolderBrowserDialog();
temp.ShowNewFolderButton = true;
temp.Description = Title;
temp.SelectedPath = InitialDirectory;
var fbd = temp;

[ahdung]

Same issue here, initializer cannot be separated from construction, if they can be separated, then it can achieved directly, not need workaround.

[TahirAhmadov]

If you mean that you would like C# to be changed so that using var folderBrowserDialog = new FolderBrowserDialog { ... }; starts behaving differently, I'm pretty sure that will not happen because it's a huge breaking change.

[ahdung]

Breaking change is not problem, context switch can handle this, technical feasibility is, I guess.

[TahirAhmadov]

It is an insurmountable problem, and if by "context switch" you mean having some kind of compiler directive or project setting which changes how this behaves, that's 99.99% not happening either, because it creates a language dialect and this issue is nowhere near the bar that's required for a language dialect.

[CyrusNajmabadi]

Breaking change is not problem

It's a def problem. Especially as the new semantics violate a design goal of initialization. If initialization fails, the assignment should not happen. That alone is a serious problem and a big deal.