[Proposal] Inline records

[VBAndCs]

I propose to allow us to define data driven records like this:

Syntax:

var x = new class Data { A= 1, 
            B = "Test",
            C = Color.Red,
            D = new struct Data2
            {
                X = 2,
                Y = DateTime.Now
            }
 };

Implementation:

This code will generate the following types:

        public class Data
        {
            public int A { get; set; }
            public string B { get; set; }
            public Color C { get; set; }
            public Data2 D { get; set; }
        }

        public struct Data2
        {
            public int X { get; set; }
            public DateTime Y { get; set; }
        }

Note: it will be better to use Records to implement this, once they are launched, but I prefer normal classes if Record will be immutable, so we can have alternative way to define mutable records. You may add default constructors and deconstructors to the implementation.

and the original code will be lowered to:

            var x = new Data
            {
                A = 1,
                B = "Test",
                C = Color.Red,
                D = new Data2
                {
                    X = 2,
                    Y = DateTime.Now
                }
            };

Benefits:

1. Compared to Records: We've defined the types and initialized vars inline with minimum possible code.
2. Compared to Anonymous Types and Tuples: We can reuse the Data and Data2 types for defining another vars or method params. Note that these types are defined inside the containing class. We can argue if they should be levered to the containg namespace or not.

[HaloFour]

The scope of something declared within a method should be that method.

Target typing the fields of a declared type will also inevitably lead to very fragile types. A tiny change that affects the expression can redefine the fields of that type causing a cascade of changes. Structure should be explicit.

[VBAndCs]

@HaloFour

The scope of something declared within a method should be that method.

You can't define classes inside methods, so, it is OK to expected them outside them. This is a new thing with new roles.

Target typing the fields of a declared type will also inevitably lead to very fragile types. A tiny change that affects the expression can redefine the fields of that type causing a cascade of changes. Structure should be explicit.

This is the same case with anonymous types and tuples. There are situations when you declare the class just to fit the data you want to bass from a controller to a view or to load some values, or return them. The expected changes are the reason that we need these classes to be auto generated to fit the data. This is some sort of dynamic object but strongly typed and has a name to allow passing it through parameters. This is a general solution for many issues I published before.

[YairHalberstadt]

You can't define classes inside methods, so, it is OK to expected them outside them. This is a new thing with new roles.

As an aside, this is really bad for incremental compilation, since you now need to bind all method bodies to provide intellisense. The performance impact of this may well be huge, and it would have to proven that this is not the case before any such feature as this could be accepted.

[VBAndCs]

@YairHalberstadt
Good point. This will need to generate the classes just after finishing writing the line they are defined in. I don't know if this is possible.

[VBAndCs]

A possible solution is to define these inline records outside methods. C# can still use type inference inside these types as it does in tuples and anonymous types.

[HaloFour]

@VBAndCs

You can't define classes inside methods, so, it is OK to expected them outside them. This is a new thing with new roles.

You can define local functions within methods, and they are limited in scope to that method. The team has expressed interest in local types as well, with similar scoping.

This is the same case with anonymous types and tuples.

It's not the same because neither create a new type that is promoted to the public surface. The scoping of the structure of an anonymous type is similarly to the method in which it is defined. You can upcast and pass it as an object, but that is expected to be brittle as you have to negotiate the instance via reflection. Where a tuple crosses a boundary you have to declare the structure and order of the tuple at that boundary, unless you box it.

Also, as you stated, you want these constructs to be mutable, but that runs counter to anonymous types, on which this syntax is based, and with records. Identity, which is a property of records, can't be established (safely) with mutability.

[VBAndCs]

@HaloFour
I am aware of all these differences, and in fact they have its advantages and disadvantages, so I proposed this to overcome these disadvantages in situation where we don't need to use the object as a key, and it is used as a container to pass some data, that its structure can be modified overtime in development, such as settings.
In fact, if this can happen in any suitable form, I would bridge it with my JSON using, by using something like:
var x = new class Data("settings.json");
where C# should pars the settings.json file, construct the Data class based on it, and populate the x instance with the values.
There can be more useful application of such semi-dynamic typing (I say 'semi' because it happens in design time only unlike F# and other languages).
I don't stick to this proposed syntax, and I will be happy if there is any appropriate way to do such data constructed records.

[HaloFour]

@VBAndCs

where C# should pars the settings.json file, construct the Data class based on it, and populate the x instance with the values

If something like that happens at all it would be through source generators, possibly like this:

[JsonClass("settings.json")]
public partial class Data { }

In which case you can have your generator code emit whatever source you want.

[jzabroski]

I quite like this idea, but more for method parameters. I wish this initial proposal were updated to make this the primary use case. When working with restrictive APIs like ASP.NET Core MVC that require [FromBody] attribute on only one parameter. A common workaround today is to use inline tuples as parameters. It only makes sense that inline records would be supported, too!

Possible Today

[Post]
public ActionResult PostData([FromBody] (int Bar, int Baz) data)
{
  var (Bar, Baz) = (data.Bar, data.Baz); // unwrap
}

• Pros: 1. Allows binding all arguments to the entire HTTP message body from the web server to the action parameters 2. As it is declared inline, there is no "type noise" and decisions that need to be made on what to name something that is fundamentally a local lexical scope naming decision. When you create a new type in a .cs file, you now have more conceptual weight to maintain, including naming the file where the type goes, and keeping that name up to date.
• Cons: You have to unwrap the data

Not Possible Today but Desired

[Post]
public ActionResult PostData(record Foo(int Bar, int Baz))

• Pros: Same as above, but no unwrapping syntax. Foo is a type, not a parameter name.
• Cons: As @YairHalberstadt mentioned, there may be a significant compiler performance penalty with stuffing type metadata at a more local lexical scope. [Proposal] Inline records #2750 (comment)

Alternatives Considered

I could use Source Generators that "thunk" all ASP.NET Core Attributes to create a tuple unwrapping layer automatically for any action that has multiple parameters. I don't really like how this reads though and seems like a Frankenstein. Sometimes the best features are "to have not at all".