Shane Krueger

I've been messing around with dynamically compiled code, reviewing the existing mechanics, and thinking about the options here. Here's my thoughts so far: 1. For source generation, `init` and `required`...

> Please explain: Coerces undefined fields to default for constructor arguments Consider: ```cs class Class1 { public string Prop1 { get; } public Class1(string prop1) { this.Prop1 = prop1; }...

> `required` or `required init` properties should be treated the same as constructor parameters - if a required field is not provided, the parsing should fail. If a property is...

> Silently choosing a constructor with the most parameters will lead to unexpected bugs. I like that answer

Generated code can use `Name = …!`. But generated code ignores compiler warnings, so it’s unlikely it would be a problem at all. Dynamic compilation knows nothing of NRT attributes,...

Note that this is generally what happens when you use GetArgument currently: default if null.

Yes, but we support multiple concurrent schemas on a single server. But typically `ToObject` is called only by `ParseDictionary`, and as such we can just generate the code within the...

> `ParseDictionary` is an instance method, so where exactly the cache will be stored? I was thinking something like this within `InputObjectGraphType`: ```cs private Func _parseDictionaryCompiled; public virtual object ParseDictionary(IDictionary...

> > we support multiple concurrent schemas on a single server. > > Can we use the schema type/name/instance as part of the cache key? Presently, `ScalarGraphType.ParseValue` and `.ParseLiteral` and...

> You mentioned the memory leak in the context of the scoped registration. In the scoped registration, this cache will be useless. Oh, I forgot, this is where source generation...