[Proposal] Factory Initializers

[codemonkeychris]

Resurrecting old design thread (apologies if I should just comment there): #6602
A motivating scenario, MVU/reactive programming models like: https://github.com/microsoft/microsoft-ui-reactor

Summary

Allow object/collection initializer syntax on the result of a method call,
not just after new. A library author opts a method into this by marking
it with a new factory modifier; callers can then write

var v = Factory(args) { X = value, Y = value };

and the trailing { … } behaves exactly like the initializer block of
new T(args) { … } — init-only and required members are assignable
inside the block, and the returned instance is sealed afterwards.

Motivation

Idiomatic C# code that consumes functional-UI libraries (React-like MVU frameworks, call-site-heavy builder APIs in general) is a
deeply-nested expression that builds a tree of immutable records via
factory calls. Today call-sites are stuck in one of two unsatisfying
shapes: fluent chains that explode for anything past 4 settings (and
require 1400+ lines of per-property extension methods on the library
side), or new T { … } object-initializer
blocks that lose the factory's positional-parameter ergonomics and
sprinkle new through every leaf of a deeply-nested tree.

Core shape

// Library declares a factory.
public static factory VStackElement VStack(double spacing = 8) =>
    new VStackElement { Spacing = spacing };

// Caller uses the trailing initializer just like on `new`.
return VStack(16) {
    Background = Surface,
    MaxWidth = 600,
    Children = [
        Text("Hello") { FontSize = 24, Weight = FontWeight.Bold },
        Button("Click me", onClick) { Padding = Thick(12) },
    ],
};

Parens are optional when the call resolves against a zero-arg overload:

return VStack { Children = [ /* ... */ ] };

Some initial questions I hit...

1. factory modifier as the gate. Trailing-initializer syntax is
   legal only when the called method (or local function) is marked
   factory. Preserves immutability by default; library authors opt in.
   Alternative: no gate — any method call. We rejected this because
   it would let callers mutate instances the library intended to be
   shared.

2. Honor-system factory in v1. The compiler does not verify
   that a factory method returns a freshly-constructed instance. We
   intend to follow up with a verification feature that restricts
   return in a factory body to new T(...) or a call to another
   factory. Is the honor-system v1 acceptable as a staging step?

3. In-place mutation, not copy. The trailing block is a continuation
   of construction on the returned instance — same semantics as
   new T { … }. We deliberately did not desugar to
   Factory() with { … }, because that would make every { … } a
   full record copy and would conflict with non-record return types.

4. Parens-optional form Name { … }. Accepts only
   { <ident> = … } lookahead; empty { } and single-element collection
   initializers ({ x }, { x, … }) require explicit (). Tighter than
   the original spec; the permissive form caused error-recovery
   regressions in existing parser tests during prototyping.

5. Children rule: Children = [...], no mixed form. We deliberately
   excluded VStack { child1, child2 } (bare children without
   Children =). It's the single biggest further ergonomic win for the
   Reactor scenarios, but the design is orthogonal: "implicit property
   name" is a follow-up feature that stacks cleanly on top of this one,
   and keeps v1 scoped to the receiver-shape change.

6. Metadata. New compiler-recognized attribute
   (System.Runtime.CompilerServices.FactoryAttribute), embedded
   following the IsExternalInit precedent. Is this the right model?

7. IOperation. Reuse IInvocationOperation; the initializer is
   reachable via ChildOperations. No new public operation kind.
   Analyzers that pattern-match on IObjectCreationOperation are
   untouched.

Open items

• Explicit-paren { } lookahead is still permissive (accepts empty
  { } and single-element collection shapes). That's caused 6
  net-new parser-test regressions in error-recovery paths where
  malformed constructs ending in (…) { } now bind as an invocation-
  with-empty-initializer. Two reasonable resolutions — tighten
  explicit-paren to match the strict parens-optional rule, or update
  the affected tests. Want LDM signal before picking.

• Attribute name. FactoryAttribute is short and matches common
  English usage; FactoryMethodAttribute is more explicit. Mild lean:
  FactoryAttribute.

• factory on extension methods, abstract/virtual methods,
  interfaces. All supported in the prototype and tested. Any LDM
  concerns?

• Expression trees. Trailing initializer inside an expression tree
  is a diagnostic, not a supported form. Same stance as with
  expressions today.

What's been validated in the prototype

With a lot of AI help, I built a prototype compiler and ran against a function creation sample with
seven scenarios and had 74 tests across parsing / semantic / emit /
IOperation / classification suites, all green.

[MattParkerDev]

FYI regarding children, in case you haven't seen it :)

#10185