Proposal: Addition of the equivalent to TypeScripts Partial<T>

[ronnyek]

When it comes to building API's I've often found the need to return a subset of fields for a given type, but not the entire type. I've also come to really love typescripts Partial<T> for things like configuration where we want to allow a user to provide a subset of options from a strongly defined type, but not necessarily the whole thing.

Potential Use Cases

• Providing a subset of strongly typed fields of an object for configuration purposes
• As the basis for deserializing passed values to a Partial<T> for building a partial update
• For filtering filtering fields based on access permissions... and not have an object with empty values, but potentially just not include the details of the field at all.

Many of the cases above, I've had to build libraries of very similar entities/models with certain fields excluded. I feel like Partial<T> could largely eliminate the need for lots of unnecessary type hierarchy. Basically any place where you are dealing with a type, and would like to have a subset of fields from a specific type... and be able to count on the fact that the fields supplied will have type safety enforced.

(BTW, if there are already suitable ways to achieve the same thing, I'd love to know how... but thus far I've seen nothing like typescripts Partial<T>)

[HaloFour]

I'm not sure there could be a good analog in C# or .NET. In TypeScript the types are just facades over the raw dictionaries of JavaScript, the members don't really exist. All Partial<T> appears to do is relax the compilers expectations as to whether those members should be populated, which was never a guarantee in the first place. But in C# those are statically-defined types and you can't implicitly "remove" whether certain members exist or are optional, not without defining a completely separate type that describes that schema. And even if you could apply a view that hides those members from an underlying type those members would still exist.

[justinmchase]

Maybe it could just be short-hand for statically defining a new type but with everything nullable.

public class Foo
{
  public int Bar { get; set; }
}

public type PartialFoo = Partial<Foo>;

which would be equivalent to

public class PartialFoo
{
  public int? Bar { get; set; }
}

[RikkiGibson]

I think a source generator would be the way to do something like this.

public class Foo
{
    public required int Thing1;
    public required int Thing2;
}

[Partial<Foo>] // come up with a term which isn't overloaded on the platform ;)
public partial class PartialFoo { }

var foo = new Foo { Thing1 = 1, Thing2 = 2 };
foo = foo.UpdateWith(new PartialFoo() { Thing1 = 1 });

[Richiban]

Maybe it could just be short-hand for statically defining a new type but with everything nullable

Even that wouldn't be particularly useful, because one of the benefits of Partial<T> is that T is assignable to Partial<T>, and that wouldn't be the case in .NET if you generated a second type based on the first.

[ronnyek]

(@HaloFour there is a blast from the past nick. I miss our long discussions about C# language features, and cross platform UI discussions from back in the day on IRC or maybe it was JabbR. I'd be genuinely curious if you still participate in those sort of communities. Miss those types of discussions)

Anyway, that is something I've considered doing as well.. is treating entities as property bags, but even then it seems like a dictionary of key/value pairs often doesn't really do much in the way of enforcing type safety for the types properties that are provided. If I could say this object represented as a sort of dictionary, but this key is of this type, and this key is of that type and know it could be enforced, that would be something I'd be willing to go with (at least for some of my needs). I just don't believe I could really do that easily with dictionary, and that there are existing types that would be more suitable.

[HaloFour]

Still on IRC, although the community isn't nearly as active as it used to be.

To me this feels like a weird mismatch between dynamic- and static-typing. I wonder if "roles" might be able to fit the bill, but I believe they're intended to be purely additive. Other than that I can only think of something involving source generators, but exactly what that looks like probably depends on the use case, I don't think it could be as general purpose as Partial<T> is. But I'm not very well versed in TypeScript either so I could be misinterpreting what it does.

[svick]

To clarify how such a type would look like in .Net: are you basically asking for Partial<T> to be a copy of T, except with all public instance properties (and constructor parameters?) turned nullable?

What would happen to logic inside property setters, which might include null checking even for non-nullable reference types? What about method parameters, which may or may not be related to properties and fields?

Also, depending on your exact requirements, you may be able to write a source generator that does what you want.

[RikkiGibson]

My head is spinning a tiny bit from overloading of the term "partial" (since partial methods and types are key to a lot of source generator patterns) 😉

[ronnyek]

Specific implementation I don't have super strong opinions... just would like a subset of the properties on the native type. I've experimented with ways to achieve this, and one of my ideas was in fact something like that, where I just build every prop as nullables... but I dont know how much that makes sense, since nullables is typically for struct/primitives.

I feel like OO programming generally tends to mean inheritance etc would always add properties, and I dont want a type that removes properties, I just want to be able to have a strongly typed subset of a full type. The one additional caveat, that potentially changes recommendations... is the list of properties contained could be dynamic. If they were always the same, I'd just build a model that represents that.

[iam3yal]

To me this reads like some sort of a proxy/trait so something like this:

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Color Color { get; set; }
}

class Student as Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Then the compiler might generate something like this:

class Student
{
    public Student(Person person) 
    {
        FirstName = person.FirstName;
        LastName = person.LastName;
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
}

But for Student to be accepted anywhere Person is WITHOUT the use of inheritance it needs CLR support that might be introduced as part of Shapes, Extensions, Roles that are discussed here #5497, #5498, #5496 by @MadsTorgersen.

[ronnyek]

I don't QUITE understand how the Roles / Extensions would help so much here, but those proposals look pretty amazing as well

[iam3yal]

Role are wrappers around existing types as noted in the proposal which is kinda similar to what I was suggesting.

Roles are transparent wrappers. They are considered identical to their underlying types and have implicit conversions in both directions. The conversions are free at runtime, because the underlying representation of the object doesn’t change.

[AartBluestoke]

This feels like it is much more reasonable if the base type is a record, as compared to anything which might carry methods that have expectations about the nature of the properties.

[iam3yal]

@ronnyek What proposal? there is no inheritance in my examples but composition or you were saying this in general?

[ronnyek]

My bad, for some reason my brain saw User as Person and automatically translated it to User: Person

[iam3yal]

@ronnyek A different syntax may be more readable but it should still be possible to do something like class Student as Person : Human {}.

[ronnyek]

Just to be clear, you aren't suggesting here that this should work today, but one way the language/compiler could be modified to handle some of this stuff?

[iam3yal]

@ronnyek Yes exactly, this isn't something that works today but I wish a variation of this may work in the future.

[ronnyek]

I think the goals for me would be... and it doesn't have to be solved via something identical to Partial<T>.

1. for say updates (via rest or whatever) provide a subset of the properties of an object and enforce the types that were provided were mapped. I think this could be huge and has been huge for me when building Typescript because my updates/mutations could literally be a Partial<T> and I map what was provided onto a populated object and I get to avoid creation of an entire other type that literally has a subset of the fields on a regular object. It also has the potential to avoid stuff like having a UserUpdateRequestObject that is basically a User object where every prop is wrapped in Optional<T> type that's like nullable except IsProvided instead of HasValue

2. Maybe this is a nitpick, but I'm frustrated that the pattern of having two types with similar shapes, and having to use something like automapper to map fields back and forth. I'm sure it can be done efficiently, but it just seems like in this day and age that it shouldn't be necessary (at least as often as it is). I feel like even if you had Person and Student as defined above (the non-inheritance example above) if you could instantiate with spread operator like you can in typescript/js

const user = { field1, field2, ... person};
const somePerson = {...user};

[ronnyek]

I realize that my scenario I lay out in automapping isn't the ONLY problem automapper solves... but its a big one (and probably the need I encounter the most)

[ronnyek]

Hotchocolate.GraphQL has a Optional<T> that can be wrapped around types, and the graphql engine effectively maps whether the property was provided in a post, and populates the value if specified. There really aren't any helpers out of box that help you apply the provided values to an instantiated object or anything.

I built a source generator that would let you mark up objects and it would generate an equivalent update object class with Optional properties instead of T, and then also generate code that would Apply those provided values on-top of the fully instantiated original entity... but I've found source generator support to be very clunky.. .and while the source generator does what I expect under unit test type scenarios, I can't seem to get it generating classes exactly where I want and accessible from places I'd normally be accessing stuff. (this is probably some slight limitations and less than ideal implementations in source generator code... but also my implementation as well)

I just feel like these scenarios are common enough where I'd prefer to avoid having to build source generators (especially with the current apis, and having to use roslyn apis to build them)

[ronnyek]

I think a source generator would be the way to do something like this.

public class Foo
{
    public required int Thing1;
    public required int Thing2;
}

[Partial<Foo>] // come up with a term which isn't overloaded on the platform ;)
public partial class PartialFoo { }

var foo = new Foo { Thing1 = 1, Thing2 = 2 };
foo = foo.UpdateWith(new PartialFoo() { Thing1 = 1 });

I actually forgot about this github issue, and was looking to do this very thing... effectively create a source generator that would generate types and their mappers for having subsets of objects that omitted fields etc.

This is exactly one of the things I thought of, using a generic attribute.

Can you even use generic attributes in generators as generators must target netstandard2.0 (which seems like it supports c# 7.3)?

[Joe4evr]

Can you even use generic attributes in generators as generators must target netstandard2.0

Since analyzers/generators are loaded in the VS process when using VS, which runs on .NET Framework, no.

[333fred]

You don't need to use them in the generator. The project that consumes the generator is the one that needs generic attributes.

[FaustVX]

Will the Source Generator be able to target something more recent than netstandard2.0 in the future ?

[RikkiGibson]

Also, this generator could probably produce code that uses System.Type/typeof() instead. Generic attributes mostly help if you need to take a parameter of the type parameter type or if you need to add constraints to the type parameter.

[333fred]

Will the Source Generator be able to target something more recent than netstandard2.0 in the future ?

Eventually, we hope so. It's not a near-term thing by any stretch, however.

[ronnyek]

So my thoughts were something like this... if we had generic attributes, and could have lambdas as properties for attributes, I could do something like this: (keep in mind just an example of syntax that would be nice... naming would differ)

public class User
{
   //...
   public int Age { get; set; }
   //...

and

[Derivative<User>]
[Except(x=>x.Age)] // even if c# supported lambda as property, not sure how this would work... magic?
public partial class UserWithoutAge
{
  
}

I think that makes for a compelling and clean way of being able to composite types on the fly, and effectively build subsets of types in a clean way that survives refactors etc.

I realize right now I could just do [Derivative(typeof(User))] and [Except("Age")] but I don't really care for magic strings that may or may not be handled in a refactor (in this case, I'm not sure I'd want my refactoring tool searching and replacing strings).

I saw someone recommend using nameof() to replace the lambda, but seems like would only work on types that have that property name local, or on parent we inherit from. (note in my example the objects don't actually have any real relation other than UserWithoutAge has same properties except age.

[RikkiGibson]

[Except(nameof(User.Age))] may have the behavior you want.

[Newex]

In the meantime I have created a very basic source generator that creates a new output source with only the properties as optional.

If anyone is interested to have a look: https://github.com/Newex/PartialSourceGen

[snowinmars-debug]

I need it for merging entities. I have default appSettings with nested properties, and any of them may be overrided. So, I want to write something like public static Config Merge(Config main, Partial<Config> other) { ... }

So, it's a usefull proposal.