Instance Blocks

[blair-ahlquist]

Whenever curly braces are used directly after an object, that object's properties and methods can be referred to directly. The return value for the resulting expression is the original object. It wouldn't be required to come directly after a constructor.

Example:

public class Example
{
    C myC;

    private doSomething(C c)
    {
        myC = c
        .{
            Name = "SomeC";
            SomethingChanged += myC_SomethingChanged;
            Initialize(i);
        };
    }
    ....
}

public class C
{
    public event EventHandler SomethingChanged;
    public string Name { get; set; }
    public void Initialize(IInterface i);
}

I set a property, registered for an event, and called a method all within the curly braces. The return value for the expression was then set to myC. This feature would largely supercede initializers.

[quinmars]

That be very nice for factory methods where you cannot use the initializer blocks, I would use a comma as separator though.

return CreateEmployee()
.{
    Name = "John",
    Age = 43
};

[blair-ahlquist]

The advantage of the semi-colons is that there is no reason to restrict what kind of code can be included inside the braces. It could function as a normal code block - with additional features.

[yaakov-h]

This is a slightly alternative syntax to that proposed in #803.

[bondsbw]

I think this is different enough from #803 to warrant a separate proposal. This one is broader, providing a block in which all visible members of the object are brought into scope. #803 (and the comment by @quinmars) are solely targeted at setting properties or fields on the object.

[bondsbw]

This proposal needs more detail, such as how scoping works. Presumably conflicting names would be resolved to the object's members.

public class A
{
    public string S => "S in A";
}

public class B
{
    string S => "S in B";

    private void MyMethod()
    {
        string S = "S local";
        new A()
        .{
            Console.WriteLine(S);        // "S in A"
            Console.WriteLine(this.S);   // "S in B"
        };
    }
}

There would be no way to access the local S within the instance block scope.

[blair-ahlquist]

I don't have a solution to that problem, but an off-the-cuff idea is to use a keyword local. I'm thinking there are other scoping issues, too - but maybe none that aren't also present elsewhere?

[bondsbw]

Even with local you have a problem of nesting:

string S = "S local";
new A()
.{
    new A()
    .{
        // Local A.S is accessible via 'local S'
        // Inner A.S is accessible via 'S'
        // Outer A.S is inaccessible
    };
};

In most other situations this is avoided by not allowing a new name to shadow existing names. this is an exception to the rule, but one that works because locals may shadow members, only.

But here it is an unavoidable issue as the inner scope is formed from existing member names. We can't say you aren't allowed to shadow, since the type is defined externally and possibly by a third party.

[blair-ahlquist]

Just to be clear about the suggestion, using your example it would be:

public class A
{
    public string S => "S in A";
}

public class B
{
    string S => "S in B";

    private void MyMethod()
    {
        string S = "S local";
        new A()
        .{
            Console.WriteLine(local.S);  // "S in MyMethod"
            Console.WriteLine(S);         // "S in A"
            Console.WriteLine(this.S);   // "S in B"
        };
    }
}

Whatever problems there are with this approach (and I'm not suggesting it is the solution), it does make the S defined in MyMethod available in the instance block. Am I missing something? local could of course be replaced with another keyword, but using a keyword at all is really the trouble.

[bondsbw]

@blair-ahlquist Notice in my last example that the new A() is nested in another new A().

[blair-ahlquist]

I totally missed that. Good example.

[bernd5]

The idea is nice - but I dislike the syntax with the dot. In addition I dislike the semicolon - we should not allow arbitrary statements in such a block / initializer.
Would it not be possible to have a syntax like we have with initializers after an object creation expression. I mean something like:

var newFoo = SomeFactoryClass.CreateFoo(){
   AFooProp = "Bar",
   Bar = 4711
};

It could be lowered simply to:

var newFoo = SomeFactoryClass.CreateFoo();
newFoo.AFooProp = "Bar";
newFoo.Bar= 4711;

And for collection initializers, it could be translated to Add-Calls.

var newFoo = SomeFactoryClass.CreatePrefilledList(){
   1, 2, 3
};

->

var newFoo = SomeFactoryClass.CreatePrefilledList();
newFoo.Add(1);
newFoo.Add(2);
newFoo.Add(3);