<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i" -->

---
title: Primary constructors are more than syntactic sugar
description: Switching from a regular constructor to a primary constructor in C# changes when fields get initialized relative to the base constructor call. With a regular...
canonical: https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Primary constructors are more than syntactic sugar | daily.dev
og:description: Switching from a regular constructor to a primary constructor in C# changes when fields get initialized relative to the base constructor call. With a regular...
og:url: https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i
og:image: https://api.daily.dev/og/posts/15IKh5h1I.png
og:image:alt: Primary constructors are more than syntactic sugar
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Primary constructors are more than syntactic sugar

**[We Are .NET](https://daily.dev/sources/wearedotnet)** · 3 min read · 2 upvotes · 0 comments

## Summary

Switching from a regular constructor to a primary constructor in C# changes when fields get initialized relative to the base constructor call. With a regular constructor, a field is assigned only after the base constructor returns, so a virtual member called from the base constructor sees null. With a primary constructor, the compiler stores the parameter in a hidden field that's assigned before the base constructor runs. Running `new Regular(3)` and `new Primary(3)` against the same base class prints 'Message = count = null' for Regular but 'Message = count = 3' for Primary. The hidden field isn't readonly, and using the parameter both in a member and a field initializer triggers warning CS9124.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://steven-giesel.com/blogPost/a3c741d3-f261-4bda-8da6-bffbbbd7aa5a>

## Questions this post answers

### Why does my C# base class constructor see a null value for a field set by a derived class primary constructor parameter?

It shouldn't, and that's the point: primary constructors assign their captured parameter to a hidden field before the base constructor runs, so virtual members called from the base constructor see the real value. A regular constructor instead assigns 'this.field' only after 'base(...)' returns, so the base constructor sees null or a default during its own execution.

_Developers debugging constructor ordering bugs in C# track compiler behavior details like this on daily.dev._

### What does the C# compiler generate differently for primary constructors versus regular constructors when a parameter is used in a virtual member?

For a regular constructor, the compiler creates a closure class to capture the parameter for a lambda, then assigns the instance field after the base constructor call. For a primary constructor, the compiler instead generates a hidden field like '<count>P' and assigns it before calling the base constructor, matching the timing of field initializers in C#.

_C# developers comparing lowered IL behavior across constructor styles can follow deep dives like this on daily.dev._

### Is the hidden field generated by a C# primary constructor parameter readonly?

No, the generated field such as '<count>P' is not readonly, so the parameter can still be reassigned inside the class without a compiler error. To get a readonly guarantee, declare the field explicitly with a field initializer like 'private readonly int? count = count;', but avoid also using the parameter in a member or the compiler warns with CS9124.

_Teams adopting C# primary constructors can keep track of these readonly gotchas on daily.dev._

## Similar posts on daily.dev

- [Why I Switched to Primary Constructors for DI in C\#](https://daily.dev/posts/why-i-switched-to-primary-constructors-for-di-in-c--ctodiijms) · Milan Jovanović · 53 upvotes · 4 comments
- [Simplify constructors with builder pattern](https://daily.dev/posts/simplify-constructors-with-builder-pattern-tz4nra6pk) · Damir's Corner · 0 upvotes · 0 comments
- [Closed class hierarchies](https://daily.dev/posts/closed-class-hierarchies-xmmjyy63z) · .NET Escapades · 15 upvotes · 0 comments

---

Tags: [#.net](https://daily.dev/tags/.net), [#c#](https://daily.dev/tags/c#)

[View this post on daily.dev](https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Primary constructors are more than syntactic sugar","url":"https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i"},"datePublished":"2026-10-26T08:49:19.380Z","dateModified":"2026-10-26T08:50:18.141Z","description":"Switching from a regular constructor to a primary constructor in C# changes when fields get initialized relative to the base constructor call. With a regular...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8255203b013bfdd3a71b03be516fb4f1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8255203b013bfdd3a71b03be516fb4f1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"We Are .NET","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"We Are .NET","logo":"https://media.daily.dev/image/upload/s--BsnVOa3i--/f_auto/v1718347410/logos/wearedotnet","url":"https://daily.dev/sources/wearedotnet"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":".net,c#","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"We Are .NET","item":"https://daily.dev/sources/wearedotnet"},{"@type":"ListItem","position":3,"name":"Primary constructors are more than syntactic sugar"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/primary-constructors-are-more-than-syntactic-sugar-15ikh5h1i#faq","mainEntity":[{"@type":"Question","name":"Why does my C# base class constructor see a null value for a field set by a derived class primary constructor parameter?","acceptedAnswer":{"@type":"Answer","text":"It shouldn't, and that's the point: primary constructors assign their captured parameter to a hidden field before the base constructor runs, so virtual members called from the base constructor see the real value. A regular constructor instead assigns 'this.field' only after 'base(...)' returns, so the base constructor sees null or a default during its own execution. Developers debugging constructor ordering bugs in C# track compiler behavior details like this on daily.dev."}},{"@type":"Question","name":"What does the C# compiler generate differently for primary constructors versus regular constructors when a parameter is used in a virtual member?","acceptedAnswer":{"@type":"Answer","text":"For a regular constructor, the compiler creates a closure class to capture the parameter for a lambda, then assigns the instance field after the base constructor call. For a primary constructor, the compiler instead generates a hidden field like '\u003ccount\u003eP' and assigns it before calling the base constructor, matching the timing of field initializers in C#. C# developers comparing lowered IL behavior across constructor styles can follow deep dives like this on daily.dev."}},{"@type":"Question","name":"Is the hidden field generated by a C# primary constructor parameter readonly?","acceptedAnswer":{"@type":"Answer","text":"No, the generated field such as '\u003ccount\u003eP' is not readonly, so the parameter can still be reassigned inside the class without a compiler error. To get a readonly guarantee, declare the field explicitly with a field initializer like 'private readonly int? count = count;', but avoid also using the parameter in a member or the compiler warns with CS9124. Teams adopting C# primary constructors can keep track of these readonly gotchas on daily.dev."}}]}
```

