Allow Default Value Declaration for Nullable Properties in DTOs

[Vamsi-MK]

Summary

In data-transfer-heavy applications (especially when interacting with databases), developers often need to assign fallback values when reading potentially null fields (e.g., from IDataReader, NpgsqlDataReader, etc.).

C# currently requires either:

1.Manually checking for DBNull on every read.
2.Using nullable fields with wrapper properties for fallback.
3.Null-coalescing logic in constructors or mapping code.
While these approaches work, they add verbosity and complexity, especially in large DTO models.

Proposal

Introduce syntax that allows defining default fallback values directly in nullable property definitions.

Suggested Syntax (for discussion):

public int? id = 0;
public string? name = "";
public DateTime? dob = DateTime.MinValue;

Or alternatively (using new property syntax):

public int? id { get; set; default 0; }
public string? name { get; set; default ""; }
public DateTime? dob { get; set; default DateTime.MinValue; }

Behavior
1.When a null value is assigned (via deserialization, manual mapping, or reflection), the defined default will be used automatically.
2.This avoids the need for explicit ?? checks or backing properties.
3.Only applies when the value is null, not when a valid non-null value is assigned.

Motivation
Today, developers often write repetitive null-handling logic like:

obj.id = reader["id"] == DBNull.Value ? 0 : (int)reader["id"];
obj.name = reader["name"] == DBNull.Value ? "" : reader["name"].ToString();
obj.dob = reader["dob"] == DBNull.Value ? DateTime.MinValue : (DateTime)reader["dob"];

Or use verbose wrappers:

private int? _id;
public int id => _id ?? 0;

This adds clutter and reduces code readability.

Benefits
1.Cleaner, more expressive DTOs.
2.Less repetitive null/DBNull checking.
3.Faster development for data-driven applications.
4.Easier deserialization from JSON/XML/db sources where nulls are common.

Considerations
1.Backward compatibility: Safe if the default fallback is optional.
2.Compiler behavior: Should ensure fallback occurs only if value is null, not when explicitly set.

Prior Art & Related Discussions
I searched existing issues and language design notes but couldn’t find a similar feature proposed or planned — apologies if I missed one.
If this overlaps with something already discussed (like auto-backing fields or property initializers), happy to learn and adapt this idea accordingly.

Closing Thoughts
This feature would enhance productivity for developers working with DTOs and bridge the gap between data access and clean domain modeling. Open to feedback, syntax suggestions, or technical concerns from the community and LDM team.

Thanks for considering it!

[CyrusNajmabadi]

public int? id { get; set; default 0; }

Isn't this just:

public int? id { get => field ?? 0; set; }

[Vamsi-MK]

Thanks again for the response, Cyrus! Let me try to give a more concrete scenario where this idea can reduce friction in real-world code.

Scenario: Reading from a database into a large DTO
Imagine we have a table called Contact, and we're reading it using NpgsqlDataReader. The table has 50+ columns, and many allow NULL.

Here's what the read logic typically looks like:

contactDto.Name = reader["Name"] == DBNull.Value ? "" : reader["Name"].ToString();
contactDto.Age = reader["Age"] == DBNull.Value ? 0 : Convert.ToInt32(reader["Age"]);
contactDto.IsActive = reader["IsActive"] == DBNull.Value ? false : Convert.ToBoolean(reader["IsActive"]);
// ...and repeat for 30–40 more fields

Yes, we could do:

contactDto.Name = reader["Name"] as string ?? "";
contactDto.Age = reader["Age"] as int? ?? 0;

But:

• That still means repeating fallback logic for each field
• Tools like NpgsqlDataReader don’t automatically honor fallback — you must handle DBNull every time manually
• Reflection or code-gen-based mappers (e.g., Dapper, custom object mappers) can't automatically infer the fallback unless it’s explicitly in the object

If the DTO looked like this:

public class ContactDto {
    public string? Name { get; set; default ""; }
    public int? Age { get; set; default 0; }
    public bool? IsActive { get; set; default false; }
}

Then the fallback would be declared once, right where it’s needed.

1. No wrapper properties
2. No constructor bloat
3. Easy for tools to reflect and apply default logic uniformly

Why it helps

1. Expresses fallback intent once, at the declaration site.
2. Easier to maintain large DTOs (especially when fields change often)
3. Reduces boilerplate and risk of human error in repetitive null-checking

I agree with your point — field ?? default is expressive. But it’s repetitive, and in these large data-mapping cases, the verbosity adds up quickly.

Hope this example clarifies where the value lies — happy to refine the idea further based on your suggestions!

[CyrusNajmabadi]

If the DTO looked like this:

public class ContactDto {
    public string? Name { get; set; default ""; }
    public int? Age { get; set; default 0; }
    public bool? IsActive { get; set; default false; }
}

I don't see how that is substantively better than my suggestion:

public class ContactDto {
    public string? Name { get => field ?? ""; set; }
    public int? Age { get => field ?? 0; set; }
    public bool? IsActive { get => field ?? false; set; }
}

It's pretty much the same length. Easy to read. Expresses the intent properly, and satisfies exactly what you asked, that there be a fallback default value for the field when null. literally field ?? ... is saying "when the field is null, return this fallback".

No wrapper properties

I don't know what this means. Both of us have properties that wrap data.

No constructor bloat

I don't know what this means. There is no constructor in my examples.

Easy for tools to reflect and apply default logic uniformly

I don't see waht about my solution is hard for tools, whereas default is easy. Indeed, i'm not sure what your code cosntruct would even compile to except the exact code i already presented :)

But it’s repetitive, and in these large data-mapping cases, the verbosity adds up quickly.

What do you mean? How is it repetitive?

Also, please stop using AI. It clearly doesn't understand what's going on here (possibly because it's trained on too old data). And it's entirely missing the point and responding with non-sensical information.

[Vamsi-MK]

What I’m mainly trying to achieve is this: regardless of the exact syntax, I want a way to automatically assign a default value when the field is null, ideally handled at the DTO/property level — especially during reads from a DataReader, deserialization, or mapping from nullable database fields.

[CyrusNajmabadi]

I want a way to automatically assign a default value when the field is null, ideally handled at the DTO/property level

I have provided a solution that does that :-)

[AartBluestoke]

@Vamsi-MK

contactDto.Name = reader["Name"] as string ?? "";
contactDto.Age = reader["Age"] as int? ?? 0;

with Cyrus's DTO your setter code doesn't need any null checks, and the reader code doesn't need any null checks - the promotion occurs silently inside the DTO.
{
contactDto.Name = reader["Name"] as string;
contactDto.Age = reader["Age"] as int?
}

and

so that
{
contactDto.Age = null;
int age = contactDto.Age; // returns 0, never null.
}

[spydacarnage]

The problem I've got with both

public string? Name { get; set; default ""; }

and

public string? Name { get => field ?? ""; set; }

is that neither of them are string? properties - they both guarantee a string value. Is there an attribute that can be applied so that null checks don't need to be done?

[CyrusNajmabadi]

can do you [AllowNull] public string Name { ... }

[spydacarnage]

That does work for string. However, it doesn't allow

[AllowNull] public int Age { get => field ?? 0; set; }

You can use

[AllowNull] public int Age { get; set; }

contactDto.Age = default;

But you can't do either of

contactDto.Age = null;
contactDto.Age = reader["Age"] as int?;

That might be why I missed or overlooked [AllowNull] when I was searching before.

[CyrusNajmabadi]

. However, it doesn't allow

This feature intentionally does not support this use case. We do not want the backing storage for a property to have a different representation than the property itself.

[spydacarnage]

Fair enough - that's why full properties are still there :-)

Thanks

[mattwar]

The database results have nulls, but you really don't want to deal with those nulls in your DTO objects or the code that uses them, so you want to translate the nulls to some other values. You are sort of mapping between domains here, but you want that mapping to be some intrinsic feature that C# or dotnet does for you.

It has problems to be a C# feature. Either the property itself is declared to accept null and the automatic mapping would intercept your ability to actual have null which would seem bad, or the property does not claim to allow null and the language would do some auto conversion from null to the property specific default value, which is not as bad but introduces some new non-intuitive magic.

It seems this is better suited for a feature of the tools you are already using (like the serializer) and represented as a custom attribute on your type in a similar way that those tools use already. You might not get any automatic benefit in code you are writing out by hand, but any tool constructing your object would benefit by having a specific default to use when attempting to assign null to a property that does not accept null.