Proposal: anonymous value types

[hez2010]

Motivation

Currently in C# we can use anonymous types by omitting the type name when instantiating an object:

var x = new { Foo = 42 };

This synthesizes a class under the hood to hold the values. But this doesn't work in cases where the receiver type requires the object to be a struct.

For example:

void Test<T>(T value) where T : struct;

Test(new { Foo = 42 }); // error

This is very inconvenient.

Besides, we have many APIs in .NET that follows a design pattern which allows us to pass a state object separately when registering a delegate to avoid capturing, eg. ThreadPool.QueueUserWorkItem, etc. Allowing to use a struct here can enable both better runtime performance and less bloating.

ThreadPool.QueueUserWorkItem(callback, state: new { ... });

A recent example that can benefit from anonymous value types immediately can be found here.

Proposal

new struct {}

Allowing struct based anonymous types by putting a struct after new.

var obj = new struct { Foo = 42 }; // struct

The above code instantiate an object of anonymous value type. The compiler will sunthesize a struct instead of a class to hold the values.

And, if any ref field is used, the compiler will synthesize a ref struct instead.

var x = 42;
var obj = new struct { Foo = ref x }; // ref struct

Anonymous value types for struct constrained generics

When the receiver type is a generic parameter that is constrained with struct or unmanaged, instantiating an anonymous object at the callsite will use structs.

void Test<T>(T value) where T : struct;

Test(new { Foo = 42 }); // okay, value is a struct

Compatibility

This is a pure addition to the language without a breaking change.

[sator-imaging]

ValueTuple seems working enough? Test(new ValueTuple<int>(42)) or Test(42).

[CyrusNajmabadi]

I don't like that argument, as effectively it's saying that totally normal C# types aren't suitable due to issues in teh runtime itself. I don't have any faith that an anonymous struct wouldn't have similar issues.

Also, the inability to use pointer types in tuples is annoying

that's not a reason for me to think we need anonymous structs.

This all feels like a slice of a slice of a slice, and doesn't warrant a large feature area like this, when it's trivially addressable with a one-line record-struct.

Note: i would be fine with working to make it possible to use pointer types in tuples. Taht itself is a limitation that makes no sense to me.

[GeeLaw]

CWT requires both the key and value to be classes:
So you could not use an anonymous value type here anyways.

But it has nothing to do with TKey, TValue. hez2010 was talking about TArg in GetOrAdd<TArg>(TKey, Func<TKey,TArg,TValue>, TArg).

That said, I'm doubtful about the value proposition of "preserving member names in type identity". If I'm not missing something, when TArg has no name at the call site, the only way to specify Func<...> is by a lambda expression right there. If Func and TArg are to be written cohered, the danger of desynchronizing member names due to identity conversion is minimal, so using a value tuple is fine. If not (say the delegate is created from a method with name, or retrieved from a member field, etc.), then it's anyway impossible to use anonymous types for TArg.

[CyrusNajmabadi]

For TArg, tuples work well. We use that pattern all over Roslyn ourselves.

[jnm2]

Note: i would be fine with working to make it possible to use pointer types in tuples. Taht itself is a limitation that makes no sense to me.

Given that the spec defines tuples in terms of ValueTuple<...> types, would this depend on generics allowing pointer types?

[CyrusNajmabadi]

Yes :)