Required properties and LINQ queries

[TahirAhmadov]

Imagine something like:

var persons = PersonsQueryable.Select(p=>new Person { FirstName = p.FirstName }).ToList();

The idea here is to reduce the load on the database and only get the first names of the people (instead of all the properties/columns).
However, if Person has required properties, this doesn't work - it won't compile with CS9035, "Required member ..."
Frankly, I'm not even sure how we could approach improving this. If a keyword is added:

var persons = PersonsQueryable.Select(p=> new partial Person { FirstName = p.FirstName }).ToList();

Here, partial basically suppresses CS9035 - this can be a pit of failure, like NRT suppress ! operator.
Alternatively, if we said that required properties are not enforced in LINQ queries, that "exemption" may be overly broad. Also, what about in-memory (IEnumerable) queries?

I'm curious if anybody has any ideas about this. In the meantime, this kind of precludes me from using required properties on domain entities.

[sharpchen]

I think partial Person should be translated to anonymous object only, but with partial type checking, so that this feature can be used elsewhere, still kind of niche.

And I prefer partial new Person instead of new partial Person

[colejohnson66]

What's the point of making it required if you want to not require it?

[TahirAhmadov]

I want to make it required when creating a new person, but like I wrote in the OP, I don't want to query all the properties all the time, for database performance reasons.

[colejohnson66]

Yes, but wouldn't the better option be to use a separate type? If you only want some of the properties, don't use an object that provides them all. Maybe even use an anonymous object. I see your point, but it feels strained.

[HaloFour]

This is where a separate DTO type would typically come into play, with mapping to a model. More boilerplate for sure, but it separates those concerns. The other option would be to project to an anonymous type, depending on what you're then doing with that result. But either way, I think attempting to break the guarantees supposedly made by required properties defeats the purpose as now the rest of the codebase needs to be aware of how you acquired this instance of Person and whether or not it can trust those particular properties to have actually been set.

[jnm2]

There are two other options:

var persons = PersonsQueryable.Select(p=> new { p.FirstName }).ToList();

And:

var persons = PersonsQueryable.Select(p=> new Person { FirstName = p.FirstName, ReqProp1 = default, ReqProp2 = default }).ToList();

[sab39]

Does Linq allow for constructor parameters in these situations? I'm imagining something like this, but I'm not sure whether it would mess up the Expression translation magic that the provider does.

public struct PartialTag {
    public static PartialTag Partial { get; } = default;
}
public class Person {
  public Person() { }
  [SetsRequiredProperties]
  public Person(PartialTag tag) { }
  public required string FirstName { get; set; }
  public required string LastName { get; set; }
}

and then in consuming code:

using static PartialTag;
var persons = PersonsQueryable.Select(p => new Person(Partial) { FirstName = p.FirstName });

(The public static property in PartialTag and the using static are purely for syntax convenience, you could drop them entirely and do new Person(default(PartialTag)) instead of new Person(Partial), but I was shooting for making the consuming code as close as possible to the original request for new partial Person)

[TahirAhmadov]

This can work, with SGs I can sprinkle those constructors for entity classes