How to Use Dart Dot Shorthands: A Handbook for Devs

<p>If you've written Flutter code for more than a month, you've likely written this line hundreds of times:</p> <pre><code class="language-dart">mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.start, mainAxisSize: MainAxisSize.min, </code></pre> <p>You know what type each of those parameters expects. The IDE knows. The Dart compiler knows. And yet every time you type it, you repeat the full type name before the dot: <code>MainAxisAlignment.center</code>. <code>CrossAxisAlignment.start</code>. <code>MainAxisSize.min</code>. Three words to say one thing, when the surrounding context has already made the type completely obvious.</p> <p>This isn't an isolated friction. It shows up everywhere in Dart and Flutter. You write <code>Colors.blue</code> on a parameter typed as <code>Color</code>. You write <code>BorderRadius.circular(8)</code> on a parameter typed as <code>BorderRadius</code>. You write <code>Duration.zero</code> on a field typed as <code>Duration</code>. You write <code>TextAlign.center</code> on a parameter typed as <code>TextAlign</code>.</p> <p>In every case, the type is already there in the parameter definition, and you're spelling it out again anyway because the language requires it.</p> <p>Dart 3.10, released on November 12, 2025 alongside Flutter 3.38, introduces dot shorthands to solve this issue. With dot shorthands, when the compiler already knows the type from context, you can write just the dot and the member name. So, for example, <code>.center</code> instead of <code>MainAxisAlignment.center</code>. <code>.circular(8)</code> instead of <code>BorderRadius.circular(8)</code>. <code>.zero</code> instead of <code>Duration.zero</code>. The type name you were spelling out is now optional, because the compiler can and will infer it.</p> <p>This isn't a cosmetic feature. It's a substantive reduction in visual noise in the places where Flutter developers write the most code: widget trees, switch statements, enum assignments, and constructor calls.</p> <p>The first time you enable it in a real codebase, your <code>Column</code> and <code>Row</code> parameters become noticeably cleaner. Your switch statements read more like prose. Your code says what it means without the prefix weight.</p> <p>This handbook is your complete guide to dot shorthands. It covers not just the syntax but the mental model behind it: why the compiler can infer types in some positions and not others, how the inference rules work, where shorthands are genuinely powerful, and where they quietly make your code harder to read.</p> <p>Many Flutter developers have seen the feature mentioned in a release note but haven't fully absorbed how deep it goes. This handbook gives you the complete picture.</p> <p>By the end, you'll be able to use dot shorthands confidently across enums, static methods, static fields, constructors, switch statements, equality checks, nullable types, and async return expressions. You'll also know the precise situations where the feature can't work and why.</p> <h2 id="heading-table-of-contents">Table of Contents</h2> <ul> <li><p><a href="#heading-prerequisites">Prerequisites</a></p> </li> <li><p><a href="#heading-what-are-dot-shorthands">What Are Dot Shorthands</a>?</p> <ul> <li><p><a href="#heading-starting-with-a-direct-analogy">Starting with a Direct Analogy</a></p> </li> <li><p><a href="#heading-the-technical-definition">The Technical Definition</a></p> </li> </ul> </li> <li><p><a href="#heading-the-problem-life-before-dot-shorthands">The Problem: Life Before Dot Shorthands</a></p> <ul> <li><p><a href="#heading-the-repetition-pattern">The Repetition Pattern</a></p> </li> <li><p><a href="#heading-the-switch-statement-problem">The Switch Statement Problem</a></p> </li> </ul> </li> <li><p><a href="#heading-the-one-rule-that-governs-everything-context">The One Rule That Governs Everything: Context</a></p> <ul> <li><a href="#heading-the-single-mental-model-you-need">The Single Mental Model You Need</a></li> </ul> </li> <li><p><a href="#heading-enums-the-primary-use-case">Enums: The Primary Use Case</a></p> <ul> <li><p><a href="#heading-why-enums-benefit-most">Why Enums Benefit Most</a></p> </li> <li><p><a href="#heading-assignments">Assignments</a></p> </li> <li><p><a href="#heading-flutter-widget-parameters">Flutter Widget Parameters</a></p> </li> <li><p><a href="#heading-enhanced-enums">Enhanced Enums</a></p> </li> <li><p><a href="#heading-inside-functions-with-enum-return-types">Inside Functions with Enum Return Types</a></p> </li> </ul> </li> <li><p><a href="#heading-static-fields-and-constants">Static Fields and Constants</a></p> <ul> <li><p><a href="#heading-static-constants">Static Constants</a></p> </li> <li><p><a href="#heading-static-fields-on-built-in-dart-types">Static Fields on Built-In Dart Types</a></p> </li> </ul> </li> <li><p><a href="#heading-static-methods">Static Methods</a></p> <ul> <li><p><a href="#heading-calling-static-methods-with-shorthands">Calling Static Methods with Shorthands</a></p> </li> <li><p><a href="#heading-in-function-arguments">In Function Arguments</a></p> </li> </ul> </li> <li><p><a href="#heading-constructors-and-named-constructors">Constructors and Named Constructors</a></p> <ul> <li><p><a href="#heading-named-constructors">Named Constructors</a></p> </li> <li><p><a href="#heading-in-widget-constructors">In Widget Constructors</a></p> </li> </ul> </li> <li><p><a href="#heading-the-new-shorthand">The .new Shorthand</a></p> <ul> <li><p><a href="#heading-invoking-the-default-constructor">Invoking the Default Constructor</a></p> </li> <li><p><a href="#heading-when-new-is-most-useful">When .new Is Most Useful</a></p> </li> </ul> </li> <li><p><a href="#heading-chaining-after-a-shorthand">Chaining After a Shorthand</a></p> <ul> <li><p><a href="#heading-chaining-instance-methods">Chaining Instance Methods</a></p> </li> <li><p><a href="#heading-why-this-matters">Why This Matters</a></p> </li> </ul> </li> <li><p><a href="#heading-equality-operators-the-special-rule">Equality Operators: The Special Rule</a></p> <ul> <li><p><a href="#heading-how-and-work-with-dot-shorthands">How == and != Work with Dot Shorthands</a></p> </li> <li><p><a href="#heading-equality-in-conditional-expressions">Equality in Conditional Expressions</a></p> </li> <li><p><a href="#heading-what-does-not-work">What Does Not Work</a></p> </li> </ul> </li> <li><p><a href="#heading-switch-statements-and-pattern-matching">Switch Statements and Pattern Matching</a></p> <ul> <li><p><a href="#heading-switch-on-enums">Switch on Enums</a></p> </li> <li><p><a href="#heading-switch-expressions">Switch Expressions</a></p> </li> <li><p><a href="#heading-pattern-matching-in-switch">Pattern Matching in Switch</a></p> </li> </ul> </li> <li><p><a href="#heading-nullable-types">Nullable Types</a></p> <ul> <li><p><a href="#heading-accessing-members-of-t-through-t">Accessing Members of T Through T?</a></p> </li> <li><p><a href="#heading-nullable-variable-assignments">Nullable Variable Assignments</a></p> </li> <li><p><a href="#heading-what-nullable-context-does-not-grant">What Nullable Context Does Not Grant</a></p> </li> </ul> </li> <li><p><a href="#heading-futureor-and-async-returns">FutureOr and Async Returns</a></p> <ul> <li><p><a href="#heading-returning-values-from-async-functions">Returning Values from Async Functions</a></p> </li> <li><p><a href="#heading-futureor-in-non-async-contexts">FutureOr in Non-Async Contexts</a></p> </li> </ul> </li> <li><p><a href="#heading-dot-shorthands-in-flutter-widget-trees">Dot Shorthands in Flutter Widget Trees</a></p> <ul> <li><a href="#heading-the-transformation-in-practice">The Transformation in Practice</a></li> </ul> </li> <li><p><a href="#heading-advanced-concepts">Advanced Concepts</a></p> <ul> <li><p><a href="#heading-where-the-inference-does-not-kick-in">Where the Inference Does Not Kick In</a></p> </li> <li><p><a href="#heading-nested-shorthands">Nested Shorthands</a></p> </li> <li><p><a href="#heading-dot-shorthands-with-extension-types">Dot Shorthands with Extension Types</a></p> </li> <li><p><a href="#heading-linter-support">Linter Support</a></p> </li> </ul> </li> <li><p><a href="#heading-best-practices">Best Practices</a></p> <ul> <li><p><a href="#heading-start-with-enums-and-switch-statements">Start With Enums and Switch Statements</a></p> </li> <li><p><a href="#heading-always-keep-the-full-form-when-type-is-genuinely-unclear">Always Keep the Full Form When Type Is Genuinely Unclear</a></p> </li> <li><p><a href="#heading-be-consistent-across-a-file-or-team">Be Consistent Across a File or Team</a></p> </li> <li><p><a href="#heading-update-your-pubspecyaml-before-using-any-shorthands">Update Your pubspec.yaml Before Using Any Shorthands</a></p> </li> </ul> </li> <li><p><a href="#heading-when-to-use-dot-shorthands-and-when-not-to">When to Use Dot Shorthands and When Not To</a></p> <ul> <li><p><a href="#heading-where-dot-shorthands-are-clearly-the-right-choice">Where Dot Shorthands Are Clearly the Right Choice</a></p> </li> <li><p><a href="#heading-where-to-prefer-the-full-form">Where to Prefer the Full Form</a></p> </li> </ul> </li> <li><p><a href="#heading-common-mistakes">Common Mistakes</a></p> <ul> <li><p><a href="#heading-using-var-instead-of-an-explicit-type">Using var Instead of an Explicit Type</a></p> </li> <li><p><a href="#heading-forgetting-to-update-the-sdk-constraint">Forgetting to Update the SDK Constraint</a></p> </li> <li><p><a href="#heading-assuming-shorthands-work-inside-generic-type-arguments">Assuming Shorthands Work Inside Generic Type Arguments</a></p> </li> <li><p><a href="#heading-over-using-shorthands-where-type-context-is-thin">Over-Using Shorthands Where Type Context Is Thin</a></p> </li> </ul> </li> <li><p><a href="#heading-mini-end-to-end-example">Mini End-to-End Example</a></p> <ul> <li><p><a href="#heading-the-enum-and-state-model">The Enum and State Model</a></p> </li> <li><p><a href="#heading-the-config-model">The Config Model</a></p> </li> <li><p><a href="#heading-the-status-widget">The Status Widget</a></p> </li> <li><p><a href="#heading-the-screen">The Screen</a></p> </li> <li><p><a href="#heading-the-entry-point">The Entry Point</a></p> </li> </ul> </li> <li><p><a href="#heading-conclusion">Conclusion</a></p> </li> <li><p><a href="#heading-references">References</a></p> </li> </ul> <h2 id="heading-prerequisites">Prerequisites</h2> <p>This guide assumes that you have some basic knowledge and skills already. You don't need to be an expert in any of these areas, but you should have a working foundation in each.</p> <p><strong>Dart fundamentals:</strong> You should understand classes, enums, static members, constructors, and named constructors. If you know the difference between <code>ClassName.member</code> and <code>instance.member</code>, and you understand what <code>static</code> means on a field or method, you're ready.</p> <p><strong>Flutter widget basics:</strong> You should be comfortable writing <code>Column</code>, <code>Row</code>, <code>Container</code>, and similar widgets. The guide uses Flutter widget parameters as the primary motivating example because that's where dot shorthands have the most visible impact.</p> <p><strong>Dart's type system:</strong> You should understand that every variable, parameter, and field in Dart has a type, and that type is either declared explicitly or inferred by the compiler. Understanding that the compiler knows types before your code runs is the foundation for understanding how context inference works.</p> <p><strong>Dart SDK 3.10 and Flutter 3.38 or higher:</strong> Dot shorthands are a language-version-gated feature. Your project must opt in to Dart 3.10. Update the SDK constraint in your <code>pubspec.yaml</code>:</p> <pre><code class="language-yaml">environment: sdk: ^3.10.0 </code></pre> <p>This constraint tells the Dart SDK that your package is written for Dart 3.10 or higher and unlocks the dot shorthand syntax for every Dart file in the project.</p> <p>Without this change, using <code>.center</code> or <code>.zero</code> will produce a compile error telling you that dot shorthand requires language version 3.10 or later. If you're using Flutter, running <code>flutter upgrade</code> and updating the SDK constraint is all that's required.</p> <p><strong>DartPad for experimentation:</strong> You can test the examples in this guide interactively at <a href="https://dartpad.dev">https://dartpad.dev</a>. DartPad supports Dart 3.10 and is the fastest way to test whether a particular shorthand works in a given context.</p> <h2 id="heading-what-are-dot-shorthands">What Are Dot Shorthands?</h2> <h3 id="heading-starting-with-a-direct-analogy">Starting with a Direct Analogy</h3> <p>Imagine you're filling out a form that has a field labeled "Country." The field already says "Country:" on the left. You write "Nigeria." You don't write "Country: Nigeria" inside the box, because the label has already told you what category the value belongs to.</p> <p>That's exactly what dot shorthands do. When Dart already knows from the surrounding context that a value must be of type <code>MainAxisAlignment</code>, you can write just <code>.center</code> instead of <code>MainAxisAlignment.center</code>. The type label is already there. The shorthand lets you write just the value.</p> <h3 id="heading-the-technical-definition">The Technical Definition</h3> <p>A dot shorthand is an expression that begins with a leading dot (<code>.</code>) and resolves to a static member access on the context type. When the compiler knows from the surrounding context that an expression must be of type <code>T</code>, writing <code>.member</code> is treated as <code>T.member</code>. Writing <code>.new(args)</code> is treated as <code>T.new(args)</code> (the unnamed constructor). Writing <code>.namedConstructor(args)</code> is treated as <code>T.namedConstructor(args)</code>.</p> <p>The key phrase is "apparent context type." The context type is the type the compiler expects at the position where you're writing the expression. It comes from:</p> <ul> <li><p>The declared type of a variable being assigned to</p> </li> <li><p>The declared type of a function parameter being passed a value</p> </li> <li><p>The declared return type of a function when a value is being returned</p> </li> <li><p>The static type of the left-hand side of a <code>==</code> or <code>!=</code> comparison (special rule)</p> </li> <li><p>The declared type of a field in an initializer</p> </li> </ul> <p>If the compiler can determine the type from one of these sources before evaluating the expression, a dot shorthand is valid at that position. If no context type is available, the dot shorthand is a compile-time error.</p> <h2 id="heading-the-problem-life-before-dot-shorthands">The Problem: Life Before Dot Shorthands</h2> <h3 id="heading-the-repetition-pattern">The Repetition Pattern</h3> <p>Open any Flutter project and look at the widget tree of a non-trivial screen. You'll see something like this:</p> <pre><code class="language-dart">Column( mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.start, mainAxisSize: MainAxisSize.min, children: [ Row( mainAxisAlignment: MainAxisAlignment.spaceBetween, crossAxisAlignment: CrossAxisAlignment.center, children: [ Text( 'Hello', textAlign: TextAlign.left, overflow: TextOverflow.ellipsis, ), Icon(Icons.chevron_right), ], ), SizedBox(height: 16), Container( alignment: Alignment.centerLeft, decoration: BoxDecoration( borderRadius: BorderRadius.circular(8), color: Colors.white, ), child: Text('World'), ), ], ) </code></pre> <p>Count the enum type name repetitions in that code. <code>MainAxisAlignment</code> appears twice. <code>CrossAxisAlignment</code> appears twice. The words <code>MainAxisAlignment</code>, <code>CrossAxisAlignment</code>, <code>TextAlign</code>, <code>TextOverflow</code>, <code>Alignment</code>, <code>BorderRadius</code>, <code>Colors</code> are all written out in full.</p> <p>And for each one, the type is already declared on the parameter: <code>mainAxisAlignment</code> takes a <code>MainAxisAlignment</code>, <code>crossAxisAlignment</code> takes a <code>CrossAxisAlignment</code>, and so on. The parameter name itself carries the type information. Yet the full type name was required before the dot.</p> <p>This wasn't just visual noise. It was cognitive noise. When reading a widget tree, the type names between the parameter name and the actual value slow the eye. Your brain reads "mainAxisAlignment colon MainAxisAlignment dot center" when all the relevant information is in "mainAxisAlignment colon center."</p> <h3 id="heading-the-switch-statement-problem">The Switch Statement Problem</h3> <p>Enum-driven switch statements had the same issue:</p> <pre><code class="language-dart">switch (status) { case NetworkStatus.connecting: return const CircularProgressIndicator(); case NetworkStatus.connected: return const Icon(Icons.wifi); case NetworkStatus.disconnected: return const Icon(Icons.wifi_off); case NetworkStatus.error: return const Icon(Icons.error); } </code></pre> <p>The variable <code>status</code> is already typed as <code>NetworkStatus</code>. Every <code>case</code> therefore operates on a <code>NetworkStatus</code> value. Writing <code>NetworkStatus.connecting</code>, <code>NetworkStatus.connected</code>, <code>NetworkStatus.disconnected</code>, and <code>NetworkStatus.error</code> in every case is pure repetition. The type name adds no information because it's already known from the switch target.</p> <p>These patterns were unavoidable before Dart 3.10. They were just the cost of the language's verbosity in static contexts.</p> <h2 id="heading-the-one-rule-that-governs-everything-context">The One Rule That Governs Everything: Context</h2> <h3 id="heading-the-single-mental-model-you-need">The Single Mental Model You Need</h3> <p>Before diving into specific use cases, internalize this single rule, because once you have it, every dot shorthand example in the language becomes obvious:</p> <p><strong>A dot shorthand works only where the compiler already knows the expected type.</strong></p> <p>That's the complete rule. Everything else is a consequence of it.</p> <p>If the compiler knows the type, <code>.member</code> resolves to <code>TypeName.member</code>. If the compiler doesn't know the type, the dot shorthand is a compile-time error. There's no guessing, no runtime inference, and no ambiguity. The compiler resolves the shorthand at compile time using the same type information it already had.</p> <p>Let's see what this means concretely:</p> <pre><code class="language-dart">// The compiler knows the type from the variable declaration. // NetworkStatus currentStatus = ... // So .connecting is NetworkStatus.connecting. This works. NetworkStatus currentStatus = .connecting; // The compiler has no type context here. // There is no surrounding variable, parameter, or declaration // to tell it what type .connecting belongs to. // This is a compile-time error. var x = .connecting; // ERROR: No context type available // The compiler knows the type from the parameter declaration. // The parameter `status` is declared as NetworkStatus. // So passing .connected resolves to NetworkStatus.connected. This works. void update(NetworkStatus status) { } update(.connected); // Works: parameter type provides context </code></pre> <p><code>NetworkStatus currentStatus = .connecting</code> works because the explicit type annotation <code>NetworkStatus</code> on the variable declaration gives the compiler all it needs.</p> <p><code>var x = .connecting</code> fails because <code>var</code> means "infer from the right-hand side," and the right-hand side starts with a dot shorthand, which itself requires context from the left-hand side. That's circular. There's no context, so there's no shorthand.</p> <p><code>update(.connected)</code> works because the function's parameter type <code>NetworkStatus</code> is the context.</p> <p>This is the single insight the entire feature is built on. Every valid and invalid example in this handbook traces back to whether a context type is available at that position.</p> <h2 id="heading-enums-the-primary-use-case">Enums: The Primary Use Case</h2> <h3 id="heading-why-enums-benefit-most">Why Enums Benefit Most</h3> <p>Enums are the primary and most recommended use case for dot shorthands for two reasons.</p> <p>First, they appear everywhere in Flutter: alignment, sizing, color schemes, text overflow, font weights, button styles, and dozens more. Second, the type context for an enum value is almost always obvious from the assignment target or the parameter being set, making the shorthand maximally unambiguous.</p> <h3 id="heading-assignments">Assignments</h3> <pre><code class="language-dart">enum Status { idle, loading, success, error } // Before Dart 3.10 Status currentStatus = Status.idle; // With dot shorthands (Dart 3.10+) Status currentStatus = .idle; </code></pre> <p>The variable declaration <code>Status currentStatus</code> provides the context type. When the compiler reaches the right-hand side and sees <code>.idle</code>, it looks up the context type (<code>Status</code>), checks that <code>Status</code> has a member named <code>idle</code>, and resolves the expression to <code>Status.idle</code>. The resulting compiled code is identical to the before version. There's no runtime difference, only a syntactic one.</p> <h3 id="heading-flutter-widget-parameters">Flutter Widget Parameters</h3> <pre><code class="language-dart">// Before Dart 3.10 Column( mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.start, mainAxisSize: MainAxisSize.min, ) // With dot shorthands (Dart 3.10+) Column( mainAxisAlignment: .center, crossAxisAlignment: .start, mainAxisSize: .min, ) </code></pre> <p>The <code>Column</code> widget's constructor declares its parameter types explicitly: <code>mainAxisAlignment</code> is <code>MainAxisAlignment</code>, <code>crossAxisAlignment</code> is <code>CrossAxisAlignment</code>, <code>mainAxisSize</code> is <code>MainAxisSize</code>. Each parameter declaration is the context type for the argument passed to it. When the compiler sees <code>.center</code> in the <code>mainAxisAlignment</code> position, the context type is <code>MainAxisAlignment</code>, so <code>.center</code> becomes <code>MainAxisAlignment.center</code>. Each shorthand resolves independently using its own parameter's declared type.</p> <p>The three-line version and the new version compile to exactly the same bytecode. The shorthand is a compile-time transformation, not a runtime one.</p> <h3 id="heading-enhanced-enums">Enhanced Enums</h3> <p>Dart's enhanced enums (introduced in Dart 2.17) can have fields, methods, and constructors. Dot shorthands work with all members that are statically accessible on the enum type:</p> <pre><code class="language-dart">enum Priority { low(1), medium(5), high(10); final int weight; const Priority(this.weight); static Priority fromWeight(int w) { if (w &lt;= 3) return low; if (w &lt;= 7) return medium; return high; } } // Dot shorthand on an enum value Priority taskPriority = .high; // Dot shorthand on a static factory method defined on the enum Priority resolved = .fromWeight(8); </code></pre> <p><code>Priority taskPriority = .high</code> uses the variable's declared type as context. <code>.high</code> resolves to <code>Priority.high</code>. <code>Priority resolved = .fromWeight(8)</code> calls the static <code>fromWeight</code> method on <code>Priority</code> without spelling out the type name. Both work because the variable type provides the context.</p> <h3 id="heading-inside-functions-with-enum-return-types">Inside Functions with Enum Return Types</h3> <pre><code class="language-dart">Priority getDefaultPriority() { return .medium; // return type provides context: Priority } </code></pre> <p>When the declared return type of a function is an enum type, the <code>return</code> statement's value has that type as its context. <code>.medium</code> resolves to <code>Priority.medium</code> because the function's return type is <code>Priority</code>. The same applies to any function, method, or getter whose return type is explicit.</p> <h2 id="heading-static-fields-and-constants">Static Fields and Constants</h2> <h3 id="heading-static-constants">Static Constants</h3> <p>Static constants, especially sentinel values like <code>Duration.zero</code>, <code>EdgeInsets.zero</code>, and <code>Offset.zero</code>, are common throughout Flutter and Dart. Dot shorthands make them noticeably cleaner:</p> <pre><code class="language-dart">// Before Dart 3.10 Duration timeout = Duration.zero; EdgeInsets padding = EdgeInsets.zero; Offset position = Offset.zero; // With dot shorthands (Dart 3.10+) Duration timeout = .zero; EdgeInsets padding = .zero; Offset position = .zero; </code></pre> <p>In each case, the variable's declared type (<code>Duration</code>, <code>EdgeInsets</code>, <code>Offset</code>) is the context. <code>.zero</code> resolves to the appropriate type's static <code>zero</code> constant in each case.</p> <p>This is particularly valuable because these zero-value sentinels appear frequently in animation code, layout code, and geometric calculations, so the repetition saving compounds across a real codebase.</p> <h3 id="heading-static-fields-on-built-in-dart-types">Static Fields on Built-In Dart Types</h3> <p>Dart's built-in types also expose static fields, and they work equally well:</p> <pre><code class="language-dart">// Duration.zero is a static field on Duration Duration animationDuration = .zero; // double.infinity is a static field on double double maxWidth = .infinity; // String.isEmpty and similar static constants on types int maxRetries = .maxFinite.toInt(); // double context, then chained </code></pre> <p><code>Duration animationDuration = .zero</code> resolves <code>.zero</code> as <code>Duration.zero</code> from the variable's type. <code>double maxWidth = .infinity</code> resolves <code>.infinity</code> as <code>double.infinity</code>. The second example also shows the beginnings of chaining, which is covered in its own section.</p> <h2 id="heading-static-methods">Static Methods</h2> <h3 id="heading-calling-static-methods-with-shorthands">Calling Static Methods with Shorthands</h3> <p>Static methods are called the same way as static fields: with a leading dot, followed by the method name and arguments. The context type tells the compiler which class to look up the method on:</p> <pre><code class="language-dart">// Before Dart 3.10 int port = int.parse('8080'); double ratio = double.parse('1.618'); DateTime now = DateTime.now(); // With dot shorthands (Dart 3.10+) int port = .parse('8080'); double ratio = .parse('1.618'); DateTime now = .now(); </code></pre> <p><code>int port = .parse('8080')</code> resolves to <code>int.parse('8080')</code> because the variable's declared type is <code>int</code>, and <code>int</code> has a static method named <code>parse</code> that accepts a <code>String</code> and returns an <code>int</code>. <code>double ratio = .parse('1.618')</code> resolves to <code>double.parse('1.618')</code> using the same mechanism. <code>DateTime now = .now()</code> resolves to <code>DateTime.now()</code> from the <code>DateTime</code> context.</p> <p>The method's return type must be compatible with the context type. If <code>int.parse</code> returned a <code>String</code>, the compiler would report a type error. The shorthand resolution happens first (find the static member on the context type), then the result is type-checked against the context as normal.</p> <h3 id="heading-in-function-arguments">In Function Arguments</h3> <pre><code class="language-dart">void configure({required Duration timeout, required int retryCount}) {} configure( timeout: .zero, // Duration context -&gt; Duration.zero retryCount: .parse('3'), // int context -&gt; int.parse('3') ); </code></pre> <p>Each named argument's declared parameter type is the context for the argument value. <code>timeout</code> is declared as <code>Duration</code>, so <code>.zero</code> resolves to <code>Duration.zero</code>. <code>retryCount</code> is declared as <code>int</code>, so <code>.parse('3')</code> resolves to <code>int.parse('3')</code>. Each argument's shorthand resolves independently using its own parameter's type.</p> <h2 id="heading-constructors-and-named-constructors">Constructors and Named Constructors</h2> <h3 id="heading-named-constructors">Named Constructors</h3> <p>Named constructors are one of Dart's most idiomatic patterns. They exist on <code>EdgeInsets</code>, <code>BorderRadius</code>, <code>Color</code>, <code>TextStyle</code>, <code>Duration</code>, and dozens of other types you use in every Flutter app. Dot shorthands work with all of them:</p> <pre><code class="language-dart">// Before Dart 3.10 EdgeInsets padding = EdgeInsets.all(16); BorderRadius radius = BorderRadius.circular(8); Color accent = Color.fromARGB(255, 66, 133, 244); TextStyle headline = TextStyle(); // With dot shorthands (Dart 3.10+) EdgeInsets padding = .all(16); BorderRadius radius = .circular(8); Color accent = .fromARGB(255, 66, 133, 244); TextStyle headline = TextStyle(); // still fine with full form too </code></pre> <p><code>EdgeInsets padding = .all(16)</code> works because <code>EdgeInsets</code> is the context type and <code>.all(16)</code> resolves to <code>EdgeInsets.all(16)</code>, which is a named constructor. <code>BorderRadius radius = .circular(8)</code> follows the same pattern.</p> <p>The full form continues to work, as dot shorthands are always optional. You choose the shorthand when it improves readability and keep the full form when the type name adds clarity.</p> <h3 id="heading-in-widget-constructors">In Widget Constructors</h3> <p>Named constructors shine in widget parameters, which is where most Flutter developers will use them most:</p> <pre><code class="language-dart">// Before Dart 3.10 Padding( padding: EdgeInsets.symmetric(horizontal: 16, vertical: 8), child: Container( decoration: BoxDecoration( borderRadius: BorderRadius.circular(12), border: Border.all(color: Colors.grey, width: 1), ), child: Text('Hello'), ), ) // With dot shorthands (Dart 3.10+) Padding( padding: .symmetric(horizontal: 16, vertical: 8), child: Container( decoration: BoxDecoration( borderRadius: .circular(12), border: .all(color: Colors.grey, width: 1), ), child: Text('Hello'), ), ) </code></pre> <p><code>padding: .symmetric(horizontal: 16, vertical: 8)</code> resolves <code>.symmetric(...)</code> as <code>EdgeInsets.symmetric(...)</code> because the <code>padding</code> parameter of <code>Padding</code> is declared as <code>EdgeInsets</code>. <code>borderRadius: .circular(12)</code> resolves as <code>BorderRadius.circular(12)</code> because the <code>borderRadius</code> field of <code>BoxDecoration</code> is typed as <code>BorderRadius?</code>. <code>border: .all(color: Colors.grey, width: 1)</code> resolves as <code>Border.all(...)</code> because the <code>border</code> field of <code>BoxDecoration</code> is typed as <code>BoxBorder?</code>, which <code>Border</code> implements.</p> <p>The shorthand resolution checks the static type of the member, not just the exact declared type.</p> <h2 id="heading-the-new-shorthand">The .new Shorthand</h2> <h3 id="heading-invoking-the-default-constructor">Invoking the Default Constructor</h3> <p>Dart's <code>ClassName.new</code> is the named reference to the unnamed default constructor. Dot shorthands support <code>.new(args)</code> as a shorthand for calling the default constructor:</p> <pre><code class="language-dart">class AppConfig { final String baseUrl; final int timeout; AppConfig(this.baseUrl, this.timeout); } // Before Dart 3.10 AppConfig config = AppConfig('https://api.example.com', 30); // With dot shorthand using .new AppConfig config = .new('https://api.example.com', 30); </code></pre> <p><code>.new('https://api.example.com', 30)</code> resolves to <code>AppConfig.new('https://api.example.com', 30)</code>, which is the same as calling <code>AppConfig('https://api.example.com', 30)</code>. The context type <code>AppConfig</code> from the variable declaration drives the resolution.</p> <h3 id="heading-when-new-is-most-useful">When .new Is Most Useful</h3> <p>The <code>.new</code> shorthand is most valuable in generic contexts and in function tear-offs, where the class name would otherwise need to be spelled out as a constructor reference.</p> <p>In direct variable assignments, it doesn't save much compared to just typing the class name, since the class name is already in the type annotation. The real benefit comes in patterns like this:</p> <pre><code class="language-dart">// A list of items where each item is constructed in place List&lt;AppConfig&gt; configs = [ .new('https://api.example.com', 30), .new('https://staging.example.com', 60), .new('https://dev.example.com', 120), ]; </code></pre> <p><code>List&lt;AppConfig&gt; configs</code> provides the context type through the list's element type <code>AppConfig</code>. Each <code>.new(...)</code> inside the list literal resolves to <code>AppConfig(...)</code>. In a list with many similar constructor calls, the shorthand removes the repetitive type prefix that would otherwise appear on every item.</p> <h2 id="heading-chaining-after-a-shorthand">Chaining After a Shorthand</h2> <h3 id="heading-chaining-instance-methods">Chaining Instance Methods</h3> <p>The dot shorthand doesn't need to be the complete expression. After the static access, you can chain instance method calls, property accesses, and other selectors. The chain can be as long as needed, as long as the final result's type is compatible with the context:</p> <pre><code class="language-dart">// Chain an instance method after a static method call int value = .parse(' 42 ').abs(); // Chain a property access after a constructor call double distance = .fromARGB(255, 255, 0, 0).opacity; // Chain a method after an enum value's instance method String statusLabel = .loading.name.toUpperCase(); </code></pre> <p><code>int value = .parse(' 42 ').abs()</code> resolves <code>.parse(' 42 ')</code> as <code>int.parse(' 42 ')</code>, which returns an <code>int</code>. Then <code>.abs()</code> is called on that <code>int</code> instance. The result is an <code>int</code>, which matches the variable's declared type.</p> <p>The shorthand only applies to the leading static access. The rest of the chain is ordinary instance member access. <code>String statusLabel = .loading.name.toUpperCase()</code> demonstrates chaining on an enum value. The context type for the shorthand resolution comes from the enum (here assumed to be a <code>Status</code> or similar), <code>.name</code> is a built-in property on every enum value that returns the value's name as a <code>String</code>, and <code>.toUpperCase()</code> is an instance method on <code>String</code>.</p> <h3 id="heading-why-this-matters">Why This Matters</h3> <p>Chaining means dot shorthands don't force you to stop at the static member. If you need to transform or access a property of the result, you can do so in the same expression. The rule is: the leading <code>.member</code> is the shorthand, everything after it is a normal instance access chain.</p> <pre><code class="language-dart">// Combining a static constructor call with a property read Color primary = .fromARGB(255, 66, 133, 244); double alpha = .fromARGB(255, 66, 133, 244).opacity; // context is double </code></pre> <p><code>Color primary = .fromARGB(255, 66, 133, 244)</code> uses the <code>Color</code> context to resolve the shorthand. <code>double alpha = .fromARGB(255, 66, 133, 244).opacity</code> has <code>double</code> as the context type, not <code>Color</code>. This means <code>.fromARGB</code> would need to resolve to a static method on <code>double</code> that exists, which it does not.</p> <p>This particular example would fail. The context type governs the leading access, so the context for the leading shorthand is <code>double</code>, not <code>Color</code>. This is a subtle point: when chaining, make sure the context type at the expression position matches the type you're targeting.</p> <h2 id="heading-equality-operators-the-special-rule">Equality Operators: The Special Rule</h2> <h3 id="heading-how-and-work-with-dot-shorthands">How == and != Work with Dot Shorthands</h3> <p>The <code>==</code> and <code>!=</code> operators have a special rule for dot shorthands that's different from the general context rule. When a dot shorthand appears on the right-hand side of a <code>==</code> or <code>!=</code> expression, the context type is derived from the static type of the left-hand side, not from any surrounding variable or parameter:</p> <pre><code class="language-dart">enum Color { red, green, blue } Color myColor = Color.red; // The LHS is myColor, which has static type Color. // So .green is resolved as Color.green. if (myColor == .green) { print('The color is green.'); } // Works the same with != if (myColor != .blue) { print('The color is not blue.'); } </code></pre> <p><code>myColor == .green</code> works because <code>myColor</code> is declared as <code>Color</code>, making <code>Color</code> the context for the right-hand side <code>.green</code>. The compiler resolves <code>.green</code> as <code>Color.green</code> before performing the equality comparison.</p> <p>This special rule exists because <code>==</code> expressions don't have a surrounding context type the way variable assignments do. The left-hand side is used instead.</p> <h3 id="heading-equality-in-conditional-expressions">Equality in Conditional Expressions</h3> <pre><code class="language-dart">Color selectedColor = Color.red; bool condition = true; Color inferredColor = condition ? .red : .blue; </code></pre> <p><code>Color inferredColor = condition ? .red : .blue</code> resolves both <code>.red</code> and <code>.blue</code> as <code>Color</code> values. The context type for a ternary expression comes from the assignment target's type, which is <code>Color</code>. Both branches of the ternary receive the same context type, so both shorthands resolve correctly.</p> <h3 id="heading-what-does-not-work">What Does Not Work</h3> <pre><code class="language-dart">// ERROR: No context for the shorthand on the right side // because the left side is `var`, which has no known type yet. var isMatch = someValue == .green; // FAILS if someValue's type is not clear // This works if someValue is explicitly typed Color someValue = Color.blue; bool isMatch = someValue == .green; // Works: someValue is Color </code></pre> <p><code>var isMatch = someValue == .green</code> fails when <code>someValue</code>'s type isn't inferable before evaluation. The rule depends on the static type of the left-hand side being known at compile time. If the compiler can't determine the left-hand side's type, the shorthand has no context to resolve from.</p> <h2 id="heading-switch-statements-and-pattern-matching">Switch Statements and Pattern Matching</h2> <h3 id="heading-switch-on-enums">Switch on Enums</h3> <p>Switch statements on enum values are where dot shorthands make the most dramatic readability improvement in real code. The switch target's type is used as the context for all case patterns:</p> <pre><code class="language-dart">enum AppState { loading, loaded, error, empty } AppState state = .loading; // Before Dart 3.10 switch (state) { case AppState.loading: return const CircularProgressIndicator(); case AppState.loaded: return const ContentWidget(); case AppState.error: return const ErrorWidget(); case AppState.empty: return const EmptyStateWidget(); } // With dot shorthands (Dart 3.10+) switch (state) { case .loading: return const CircularProgressIndicator(); case .loaded: return const ContentWidget(); case .error: return const ErrorWidget(); case .empty: return const EmptyStateWidget(); } </code></pre> <p><code>state</code> is declared as <code>AppState</code>, making <code>AppState</code> the context type for every case in the switch. Each <code>.loading</code>, <code>.loaded</code>, <code>.error</code>, and <code>.empty</code> resolves to the corresponding <code>AppState</code> value. The switch is exhaustive – checking works the same way. The compiler still verifies that all enum cases are covered.</p> <h3 id="heading-switch-expressions">Switch Expressions</h3> <p>Dart's switch expressions (the expression form that returns a value) work identically:</p> <pre><code class="language-dart">Widget content = switch (state) { .loading =&gt; const CircularProgressIndicator(), .loaded =&gt; const ContentWidget(), .error =&gt; const ErrorWidget(), .empty =&gt; const EmptyStateWidget(), }; </code></pre> <p><code>switch (state)</code> where <code>state</code> is <code>AppState</code> provides <code>AppState</code> as the context for each pattern on the left side of the <code>=&gt;</code>. Each <code>.loading</code>, <code>.loaded</code>, <code>.error</code>, and <code>.empty</code> resolves to the corresponding <code>AppState</code> value. The right side of each <code>=&gt;</code> arrow isn't affected by the switch context; each <code>=&gt;</code> branch is a normal expression.</p> <h3 id="heading-pattern-matching-in-switch">Pattern Matching in Switch</h3> <pre><code class="language-dart">void handleResult(Result result) { switch (result) { case .success when result.value &gt; 0: print('Positive success: ${result.value}'); case .success: print('Non-positive success'); case .failure: print('Failed: ${result.error}'); } } </code></pre> <p>Guard clauses (<code>when</code>) work naturally alongside dot shorthands. <code>.success when result.value &gt; 0</code> is a case pattern for the enum value <code>Result.success</code> with an additional guard condition. The shorthand resolves to the enum value for matching purposes, and the guard is evaluated separately.</p> <h2 id="heading-nullable-types">Nullable Types</h2> <h3 id="heading-accessing-members-of-t-through-t">Accessing Members of <code>T</code> Through <code>T?</code></h3> <p>When a variable or parameter has a nullable type <code>T?</code>, you can still use dot shorthands to access static members of the underlying type <code>T</code>. The Dart specification explicitly allows this:</p> <pre><code class="language-dart">// A parameter typed as nullable Status void updateStatus(Status? newStatus) { // You can pass a non-null Status value using a shorthand } updateStatus(.loading); // passes Status.loading, which is a valid Status? </code></pre> <p><code>updateStatus(.loading)</code> works because the parameter type <code>Status?</code> provides a context of <code>Status?</code>, and the dot shorthand rules allow accessing members of <code>Status</code> in a <code>Status?</code> context. The value <code>.loading</code> resolves to <code>Status.loading</code>, which is a non-null <code>Status</code>, and non-null values are always valid in a nullable position.</p> <h3 id="heading-nullable-variable-assignments">Nullable Variable Assignments</h3> <pre><code class="language-dart">Status? maybeStatus = .error; // Assigns Status.error to a Status? variable Status? nothing = null; // Still works; null is valid for Status? </code></pre> <p><code>Status? maybeStatus = .error</code> resolves <code>.error</code> as <code>Status.error</code> (from the <code>Status?</code> context), which is then assigned to the nullable variable. The nullability of the type doesn't prevent the shorthand from working – it just means the variable can also hold null. The shorthand always produces a non-null value of the underlying type.</p> <h3 id="heading-what-nullable-context-does-not-grant">What Nullable Context Does Not Grant</h3> <p>The nullable context allows accessing members of <code>T</code>, but not members of <code>Null</code>. <code>Null</code> has no useful static members for this purpose, and the feature doesn't expose them:</p> <pre><code class="language-dart">// This resolves to Duration.zero (from the Duration? context's underlying Duration type) Duration? elapsed = .zero; // You cannot access static members of Null through a nullable context // There are no meaningful Null static members to access </code></pre> <p><code>Duration? elapsed = .zero</code> resolves <code>.zero</code> as <code>Duration.zero</code> from the <code>Duration?</code> context. The nullable wrapper is transparent for the purposes of static member lookup.</p> <h2 id="heading-futureor-and-async-returns">FutureOr and Async Returns</h2> <h3 id="heading-returning-values-from-async-functions">Returning Values from Async Functions</h3> <p>Inside an <code>async</code> function, the effective return type of every <code>return</code> statement is <code>FutureOr&lt;T&gt;</code> where <code>T</code> is the declared return type. The dot shorthand specification explicitly handles this case by allowing <code>T</code>'s static members to be accessed in a <code>FutureOr&lt;T&gt;</code> context:</p> <pre><code class="language-dart">Future&lt;Status&gt; fetchStatus() async { // The function's declared return type is Future&lt;Status&gt;. // Inside an async function, return accepts a FutureOr&lt;Status&gt;. // Dot shorthand resolves .loaded as Status.loaded. return .loaded; } </code></pre> <p><code>return .loaded</code> inside a <code>Future&lt;Status&gt;</code> async function works because the async function's return context is <code>FutureOr&lt;Status&gt;</code>, and the dot shorthand rules allow accessing <code>Status</code> members through a <code>FutureOr&lt;Status&gt;</code> context.</p> <p>The Dart team specifically decided to support this case because returning bare values from async functions is extremely common, and requiring <code>Status.loaded</code> when the function's return type already says <code>Status</code> was seen as unnecessary verbosity.</p> <h3 id="heading-futureor-in-non-async-contexts">FutureOr in Non-Async Contexts</h3> <pre><code class="language-dart">FutureOr&lt;Duration&gt; getDelay() { // Can return either a Duration or a Future&lt;Duration&gt; return .zero; // Resolves to Duration.zero } </code></pre> <p><code>return .zero</code> in a function returning <code>FutureOr&lt;Duration&gt;</code> resolves <code>.zero</code> as <code>Duration.zero</code> because the <code>FutureOr&lt;Duration&gt;</code> context grants access to <code>Duration</code>'s members. The returned value is a synchronous <code>Duration</code>, which is a valid <code>FutureOr&lt;Duration&gt;</code>.</p> <h2 id="heading-dot-shorthands-in-flutter-widget-trees">Dot Shorthands in Flutter Widget Trees</h2> <h3 id="heading-the-transformation-in-practice">The Transformation in Practice</h3> <p>Flutter widget trees are the most impactful place to see dot shorthands in action, because they contain the most enum values and named constructors in any Flutter codebase.</p> <p>Here's a realistic profile card widget, before and after:</p> <pre><code class="language-dart">// Before Dart 3.10: A profile card widget class ProfileCard extends StatelessWidget { final String name; final String role; final bool isOnline; const ProfileCard({ super.key, required this.name, required this.role, required this.isOnline, }); @override Widget build(BuildContext context) { return Card( elevation: 2, child: Padding( padding: EdgeInsets.all(16), child: Row( mainAxisAlignment: MainAxisAlignment.start, crossAxisAlignment: CrossAxisAlignment.center, children: [ CircleAvatar( backgroundColor: isOnline ? Colors.green : Colors.grey, radius: 24, child: Text( name[0].toUpperCase(), style: TextStyle( color: Colors.white, fontWeight: FontWeight.bold, ), ), ), SizedBox(width: 12), Expanded( child: Column( mainAxisSize: MainAxisSize.min, crossAxisAlignment: CrossAxisAlignment.start, children: [ Text( name, style: TextStyle( fontWeight: FontWeight.w600, overflow: TextOverflow.ellipsis, ), ), Text( role, style: TextStyle( color: Colors.grey, fontSize: 12, ), ), ], ), ), Icon( isOnline ? Icons.circle : Icons.circle_outlined, color: isOnline ? Colors.green : Colors.grey, size: 12, ), ], ), ), ); } } </code></pre> <p>This is clean, idiomatic Flutter code. But look at how much is repeated: the full type names for every enum value and every constructor call.</p> <p>Now the same thing with dot shorthands:</p> <pre><code class="language-dart">// With dot shorthands (Dart 3.10+) class ProfileCard extends StatelessWidget { final String name; final String role; final bool isOnline; const ProfileCard({ super.key, required this.name, required this.role, required this.isOnline, }); @override Widget build(BuildContext context) { return Card( elevation: 2, child: Padding( padding: .all(16), child: Row( mainAxisAlignment: .start, crossAxisAlignment: .center, children: [ CircleAvatar( backgroundColor: isOnline ? Colors.green : Colors.grey, radius: 24, child: Text( name[0].toUpperCase(), style: TextStyle( color: Colors.white, fontWeight: .bold, ), ), ), const SizedBox(width: 12), Expanded( child: Column( mainAxisSize: .min, crossAxisAlignment: .start, children: [ Text( name, style: TextStyle( fontWeight: .w600, overflow: .ellipsis, ), ), Text( role, style: TextStyle( color: Colors.grey, fontSize: 12, ), ), ], ), ), Icon( isOnline ? Icons.circle : Icons.circle_outlined, color: isOnline ? Colors.green : Colors.grey, size: 12, ), ], ), ), ); } } </code></pre> <p><code>padding: .all(16)</code> resolves to <code>EdgeInsets.all(16)</code> because <code>Padding.padding</code> is typed <code>EdgeInsets</code>. <code>mainAxisAlignment: .start</code> resolves to <code>MainAxisAlignment.start</code> because <code>Row.mainAxisAlignment</code> is typed <code>MainAxisAlignment</code>. <code>crossAxisAlignment: .center</code> resolves to <code>CrossAxisAlignment.center</code>. <code>fontWeight: .bold</code> resolves to <code>FontWeight.bold</code> because <code>TextStyle.fontWeight</code> is <code>FontWeight?</code>. <code>mainAxisSize: .min</code> resolves to <code>MainAxisSize.min</code>. <code>overflow: .ellipsis</code> resolves to <code>TextOverflow.ellipsis</code>.</p> <p>Each shorthand is driven by the declaring parameter's type.</p> <p>The before and after produce identical compiled output. The difference is purely in how the source reads: with shorthands, the parameter name and the value are adjacent, and the eye moves cleanly from one to the other without wading through the repeated type names.</p> <h2 id="heading-advanced-concepts">Advanced Concepts</h2> <h3 id="heading-where-the-inference-does-not-kick-in">Where the Inference Does Not Kick In</h3> <p>Understanding the failure cases is as important as understanding the success cases. The following situations don't provide a context type and so don't support dot shorthands:</p> <pre><code class="language-dart">// var infers from the RHS, but RHS needs LHS context: circular, fails var status = .loading; // ERROR // The list literal does not know its element type from a leading dot var items = [.loading, .error]; // ERROR: var provides no context // Explicitly typed list works fine List&lt;Status&gt; items = [.loading, .error]; // Works // Dynamic removes type information entirely dynamic value = .loading; // ERROR: dynamic is not a usable context type // Conditional assignment where context is ambiguous Object status = condition ? .loading : 'string'; // ERROR: Object too broad </code></pre> <p><code>var status = .loading</code> fails because <code>var</code> means the type is inferred from the right-hand side, but the right-hand side (the shorthand) needs the left-hand type for context. It's circular.</p> <p><code>var items = [.loading, .error]</code> fails for the same reason: the list's element type would come from its contents, but the contents need the element type.</p> <p><code>List&lt;Status&gt; items = [.loading, .error]</code> works because the explicit type annotation gives the compiler the <code>Status</code> context before it evaluates the list elements.</p> <p>But <code>dynamic value = .loading</code> fails because <code>dynamic</code> bypasses the type system and doesn't provide a usable static context type for member lookup.</p> <h3 id="heading-nested-shorthands">Nested Shorthands</h3> <p>A "nested shorthand" is when you attempt to use a dot shorthand inside an expression that is itself using a dot shorthand. The outer shorthand's resolution doesn't propagate its type as context into nested positions:</p> <pre><code class="language-dart">// The outer shorthand resolves from the BoxDecoration context BoxDecoration decoration = BoxDecoration( borderRadius: .circular(8), // Outer shorthand: BorderRadius.circular(8) border: .all( // Outer shorthand: Border.all(...) color: Colors.grey, width: 1, ), ); </code></pre> <p>This works. Each shorthand resolves independently: <code>.circular(8)</code> from the <code>BorderRadius?</code> context of <code>boxDecoration.borderRadius</code>, and <code>.all(...)</code> from the <code>BoxBorder?</code> context of <code>boxDecoration.border</code>. They aren't nested in the sense of depending on each other.</p> <p>A truly nested shorthand would be using a shorthand inside the arguments of another shorthand's call:</p> <pre><code class="language-dart">// Attempting to use a shorthand inside another shorthand's arguments EdgeInsets padding = .fromLTRB( .zero.left, // ERROR: .zero has no context here 8, 8, 8, ); </code></pre> <p><code>.zero.left</code> fails because <code>.zero</code> inside the argument to <code>.fromLTRB</code> doesn't have an established context type. The DCM linter provides an <code>avoid-nested-shorthands</code> rule that flags these cases. The fix is always to be explicit in the inner position where context is unclear:</p> <pre><code class="language-dart">EdgeInsets padding = .fromLTRB( EdgeInsets.zero.left, // Explicit: fine 8, 8, 8, ); </code></pre> <h3 id="heading-dot-shorthands-with-extension-types">Dot Shorthands with Extension Types</h3> <p>Extension types (introduced in Dart 3.3) also support dot shorthands. If an extension type has static members, they can be accessed with a shorthand when the extension type is the context:</p> <pre><code class="language-dart">extension type Milliseconds(int value) { static Milliseconds get zero =&gt; Milliseconds(0); static Milliseconds fromSeconds(int seconds) =&gt; Milliseconds(seconds * 1000); } Milliseconds delay = .zero; // Milliseconds.zero Milliseconds timeout = .fromSeconds(5); // Milliseconds.fromSeconds(5) </code></pre> <p><code>Milliseconds delay = .zero</code> resolves <code>.zero</code> as <code>Milliseconds.zero</code> from the variable's declared type. <code>Milliseconds timeout = .fromSeconds(5)</code> resolves the static factory method on <code>Milliseconds</code>.</p> <p>Extension types are still relatively new, but their support for dot shorthands means you can design them with the same shorthand-friendly static member API that built-in types have.</p> <h3 id="heading-linter-support">Linter Support</h3> <p>The DCM (Dart Code Metrics) tool provides four lint rules specifically for dot shorthands, which help enforce consistent adoption:</p> <pre><code class="language-yaml"># analysis_options.yaml (using DCM) dcm: rules: - prefer-shorthands-with-enums - prefer-shorthands-with-static-fields - prefer-returning-shorthands - prefer-shorthands-with-constructors: entries: - EdgeInsets - BorderRadius - Radius - Border - Duration - avoid-nested-shorthands </code></pre> <p><code>prefer-shorthands-with-enums</code> flags any enum value access where the type name could be dropped because context makes it clear. <code>prefer-shorthands-with-static-fields</code> does the same for static field accesses. <code>prefer-returning-shorthands</code> flags return statements where the type name could be omitted. <code>prefer-shorthands-with-constructors</code> with an <code>entries</code> list flags specific classes where named constructor calls could use shorthands. <code>avoid-nested-shorthands</code> flags the problematic nested cases described above.</p> <p>Enabling these rules gradually (starting with <code>prefer-shorthands-with-enums</code>, the most impactful) is the recommended migration strategy for an existing codebase.</p> <h2 id="heading-best-practices">Best Practices</h2> <h3 id="heading-start-with-enums-and-switch-statements">Start With Enums and Switch Statements</h3> <p>The highest-value, lowest-risk places to adopt dot shorthands are enum assignments and switch case patterns. These are the cases where the type context is most obvious to any reader, the compiler's inference is most reliable, and the readability gain is highest. Migrate these first in any existing codebase.</p> <h3 id="heading-always-keep-the-full-form-when-type-is-genuinely-unclear">Always Keep the Full Form When Type Is Genuinely Unclear</h3> <p>The goal of dot shorthands is to reduce noise, not to introduce ambiguity. When a shorthand makes a reader pause and wonder what type the dot refers to, use the full form.</p> <p>A concrete signal: if you would need to hover over the expression in your IDE to know what type it resolves to, the full form is more appropriate.</p> <pre><code class="language-dart">// Clear: the parameter name `alignment` tells you the type alignment: .centerLeft, // Less clear in isolation: what type does .fromARGB belong to? // The full form communicates more clearly here color: Color.fromARGB(255, 66, 133, 244), // more readable than .fromARGB </code></pre> <p><code>alignment: .centerLeft</code> is clear because the parameter name <code>alignment</code> strongly implies <code>Alignment</code>. <code>Color.fromARGB(...)</code> is more readable than <code>.fromARGB(...)</code> because <code>fromARGB</code> as a method name doesn't clearly signal which type it comes from, and <code>Color</code> in front of it removes any ambiguity instantly.</p> <h3 id="heading-be-consistent-across-a-file-or-team">Be Consistent Across a File or Team</h3> <p>Inconsistency is worse than either consistent adoption or consistent avoidance. If half your widget tree uses shorthands and half uses full forms, the code looks inconsistent and the mix of styles creates cognitive load.</p> <p>Pick a convention for your team: either adopt shorthands for enums and avoid them for constructors, or adopt them across the board for types where the parameter name makes the type obvious.</p> <h3 id="heading-update-your-pubspecyaml-before-using-any-shorthands">Update Your pubspec.yaml Before Using Any Shorthands</h3> <p>The feature is gated on the language version. Using a shorthand in a file under a project that hasn't updated its SDK constraint will produce a compile error.</p> <p>Update the constraint before adopting the syntax:</p> <pre><code class="language-yaml">environment: sdk: ^3.10.0 </code></pre> <p><code>sdk: ^3.10.0</code> means "Dart 3.10.0 or any higher patch or minor version, but not 4.0 or higher." This is the standard constraint for Dart 3 projects. If your team has a monorepo with multiple packages, each package's <code>pubspec.yaml</code> needs its own updated constraint for that package to use dot shorthands.</p> <h2 id="heading-when-to-use-dot-shorthands-and-when-not-to">When to Use Dot Shorthands and When Not To</h2> <h3 id="heading-where-dot-shorthands-are-clearly-the-right-choice">Where Dot Shorthands Are Clearly the Right Choice</h3> <p>Enum values in Flutter widget parameters are the canonical use case. <code>mainAxisAlignment: .center</code>, <code>crossAxisAlignment: .start</code>, <code>mainAxisSize: .min</code>, <code>textAlign: .left</code> are all unambiguous, save significant horizontal space in already-deep widget trees, and make the code read more naturally.</p> <p>Switch statements on enums are the second canonical case. Every case in a switch on a typed enum variable can use a shorthand, and the result is switch statements that read as a list of values rather than a list of prefixed type-and-value pairs.</p> <p>Well-known sentinels like <code>.zero</code>, <code>.empty</code>, <code>.none</code> on types where that member is universally understood are also excellent candidates. <code>Duration timeout = .zero</code> is clearer than <code>Duration timeout = Duration.zero</code> because the context gives you the type and <code>zero</code> is a universally understood sentinel.</p> <h3 id="heading-where-to-prefer-the-full-form">Where to Prefer the Full Form</h3> <p>Any constructor or static method call where the method name doesn't clearly signal the type is a case for the full form. <code>.fromARGB(255, 66, 133, 244)</code> is not as self-explanatory as <code>Color.fromARGB(255, 66, 133, 244)</code>. The explicit type name acts as documentation.</p> <p>Any context where a new developer might not know what type they're looking at deserves the full form. If a parameter is named <code>config</code> and the type is a custom class <code>ServerConfig</code>, writing <code>.defaults()</code> is less clear than <code>ServerConfig.defaults()</code> because <code>config</code> is a vague name and the shorthand hides the class being instantiated.</p> <p>Any place where two different types have a static member with the same name, and both could plausibly be the context type, should use the full form to remove any possible confusion. Even if the compiler is unambiguous, human readers may not be.</p> <h2 id="heading-common-mistakes">Common Mistakes</h2> <h3 id="heading-using-var-instead-of-an-explicit-type">Using var Instead of an Explicit Type</h3> <p>The most common beginner mistake with dot shorthands is trying to use them with <code>var</code>:</p> <pre><code class="language-dart">// ERROR: var cannot provide a context type var status = .loading; // CORRECT: explicit type annotation provides the context Status status = .loading; </code></pre> <p><code>var status = .loading</code> looks like it should work because <code>var</code> eventually gets inferred as <code>Status</code> if you assign a <code>Status</code> value. But type inference for <code>var</code> works by looking at the right-hand side first, and the right-hand side (the shorthand) needs the left-hand type to resolve.</p> <p><code>var</code> doesn't provide a type before evaluation – it defers to the evaluation result. The fix is always to add the explicit type annotation, which is a one-word change and the result is cleaner code.</p> <h3 id="heading-forgetting-to-update-the-sdk-constraint">Forgetting to Update the SDK Constraint</h3> <pre><code class="language-yaml"># BEFORE: Will not support dot shorthands environment: sdk: ^3.9.0 # AFTER: Enables dot shorthands for all files in this package environment: sdk: ^3.10.0 </code></pre> <p>Attempting to use <code>.loading</code> or any other shorthand in a project with the old constraint produces a compile error that points to the language version. The fix is to update the <code>sdk</code> constraint in <code>pubspec.yaml</code>, then run <code>flutter pub get</code> or <code>dart pub get</code>. No code changes are needed beyond the <code>pubspec.yaml</code> update to enable the feature.</p> <h3 id="heading-assuming-shorthands-work-inside-generic-type-arguments">Assuming Shorthands Work Inside Generic Type Arguments</h3> <pre><code class="language-dart">// ERROR: Type arguments do not provide a shorthand context List&lt;.center&gt; items; // Meaningless and invalid Map&lt;String, .loading&gt; cache; // Invalid </code></pre> <p>Type argument positions (the <code>&lt;T&gt;</code> in generic types) aren't expression positions. They can't contain dot shorthands.</p> <p>A dot shorthand must be a value expression, not a type expression. This distinction is clear once stated but can trip up developers who are getting comfortable with how broadly shorthands apply.</p> <h3 id="heading-over-using-shorthands-where-type-context-is-thin">Over-Using Shorthands Where Type Context Is Thin</h3> <pre><code class="language-dart">// Problematic: the shorthand obscures which type fromJSON belongs to SomeConfig config = .fromJSON(data); // What class is this? // Better: be explicit when the type name adds real information SomeConfig config = SomeConfig.fromJSON(data); </code></pre> <p><code>.fromJSON(data)</code> is a shorthand that technically works if <code>SomeConfig</code> is the context type, but <code>fromJSON</code> as a method name is generic enough that a reader encountering it for the first time wouldn't know which class it comes from without looking at the variable's type. Including <code>SomeConfig</code> explicitly in the constructor call makes it immediately readable. Not every valid shorthand is an improvement.</p> <h2 id="heading-mini-end-to-end-example">Mini End-to-End Example</h2> <p>Let's build a complete, realistic feature that demonstrates dot shorthands across every major context: enums, static methods, named constructors, switch statements, and Flutter widget parameters.</p> <p>The feature is a network status indicator widget for an app that shows different UI states based on connection status.</p> <h3 id="heading-the-enum-and-state-model">The Enum and State Model</h3> <pre><code class="language-dart">// lib/models/connection_state.dart enum ConnectionState { connecting, connected, disconnected, limited, error; bool get isActive =&gt; this == .connected || this == .limited; bool get isTerminal =&gt; this == .disconnected || this == .error; static ConnectionState fromCode(int code) { return switch (code) { 0 =&gt; .connecting, 1 =&gt; .connected, 2 =&gt; .limited, 3 =&gt; .disconnected, _ =&gt; .error, }; } String get label =&gt; switch (this) { .connecting =&gt; 'Connecting...', .connected =&gt; 'Connected', .disconnected =&gt; 'Disconnected', .limited =&gt; 'Limited Connection', .error =&gt; 'Connection Error', }; } </code></pre> <p><code>bool get isActive =&gt; this == .connected || this == .limited</code> uses the <code>==</code> special rule. <code>this</code> is a <code>ConnectionState</code> instance, so <code>this == .connected</code> resolves <code>.connected</code> as <code>ConnectionState.connected</code> from the static type of the left-hand side <code>this</code>.</p> <p><code>static ConnectionState fromCode(int code)</code> is a static factory method on the enum. Inside the switch expression, the return type <code>ConnectionState</code> provides context for each <code>=&gt;</code> result. <code>.connecting</code> resolves to <code>ConnectionState.connecting</code>, <code>.connected</code> to <code>ConnectionState.connected</code>, and so on.</p> <p>The <code>_</code> wildcard case returns <code>.error</code>, which also resolves to <code>ConnectionState.error</code>. <code>String get label</code> uses a switch expression on <code>this</code>, which is typed <code>ConnectionState</code>, providing context for the case patterns. Each <code>.connecting</code>, <code>.connected</code>, <code>.disconnected</code>, <code>.limited</code>, and <code>.error</code> resolves to the corresponding enum value.</p> <h3 id="heading-the-config-model">The Config Model</h3> <pre><code class="language-dart">// lib/models/network_config.dart class NetworkConfig { final Duration timeout; final int maxRetries; final bool showDetailedErrors; const NetworkConfig({ required this.timeout, required this.maxRetries, required this.showDetailedErrors, }); factory NetworkConfig.standard() { return NetworkConfig( timeout: .zero, // Duration context -&gt; Duration.zero maxRetries: .parse('3'), // int context -&gt; int.parse('3') showDetailedErrors: false, ); } factory NetworkConfig.debug() { return NetworkConfig( timeout: .fromSeconds(60), // Duration context -&gt; Duration.fromSeconds(60) maxRetries: .parse('10'), // int context -&gt; int.parse('10') showDetailedErrors: true, ); } } </code></pre> <p><code>timeout: .zero</code> uses the field's declared type <code>Duration</code> as context. <code>.zero</code> resolves to <code>Duration.zero</code>. <code>maxRetries: .parse('3')</code> uses the field's declared type <code>int</code> as context. <code>.parse('3')</code> resolves to <code>int.parse('3')</code>, which returns an <code>int</code>. <code>timeout: .fromSeconds(60)</code> resolves to <code>Duration.fromSeconds(60)</code>, a named constructor on <code>Duration</code>.</p> <p>These are simple but realistic patterns: factory constructors that use static methods and sentinels from other types, now without spelling out those types.</p> <h3 id="heading-the-status-widget">The Status Widget</h3> <pre><code class="language-dart">// lib/widgets/connection_status_widget.dart import 'package:flutter/material.dart'; import '../models/connection_state.dart'; class ConnectionStatusWidget extends StatelessWidget { final ConnectionState state; final VoidCallback? onRetry; const ConnectionStatusWidget({ super.key, required this.state, this.onRetry, }); @override Widget build(BuildContext context) { return AnimatedSwitcher( duration: .fromMilliseconds(300), // Duration context child: _buildContent(context), ); } Widget _buildContent(BuildContext context) { return Padding( padding: .symmetric(horizontal: 16, vertical: 12), // EdgeInsets context child: Row( mainAxisAlignment: .spaceBetween, // MainAxisAlignment context crossAxisAlignment: .center, // CrossAxisAlignment context children: [ Row( mainAxisSize: .min, // MainAxisSize context children: [ _buildIcon(), const SizedBox(width: 8), Text( state.label, style: TextStyle( fontWeight: .w500, // FontWeight context color: _textColor(), ), ), ], ), if (state == .error &amp;&amp; onRetry != null) TextButton( onPressed: onRetry, child: const Text('Retry'), ), ], ), ); } Widget _buildIcon() { final (IconData icon, Color color) = switch (state) { .connecting =&gt; (Icons.sync, Colors.orange), .connected =&gt; (Icons.wifi, Colors.green), .disconnected =&gt; (Icons.wifi_off, Colors.grey), .limited =&gt; (Icons.signal_wifi_4_bar_lock, Colors.amber), .error =&gt; (Icons.error_outline, Colors.red), }; return Icon(icon, color: color, size: 18); } Color _textColor() =&gt; switch (state) { .connected =&gt; Colors.green, .error =&gt; Colors.red, .disconnected =&gt; Colors.grey, _ =&gt; Colors.orange, }; } </code></pre> <p><code>duration: .fromMilliseconds(300)</code> resolves to <code>Duration.fromMilliseconds(300)</code> because <code>AnimatedSwitcher.duration</code> is typed <code>Duration</code>. <code>padding: .symmetric(horizontal: 16, vertical: 12)</code> resolves to <code>EdgeInsets.symmetric(...)</code> because <code>Padding.padding</code> is typed <code>EdgeInsets</code>. <code>mainAxisAlignment: .spaceBetween</code> resolves to <code>MainAxisAlignment.spaceBetween</code>. <code>crossAxisAlignment: .center</code> resolves to <code>CrossAxisAlignment.center</code>. <code>mainAxisSize: .min</code> resolves to <code>MainAxisSize.min</code>. <code>fontWeight: .w500</code> resolves to <code>FontWeight.w500</code> because <code>TextStyle.fontWeight</code> is <code>FontWeight?</code>.</p> <p><code>if (state == .error &amp;&amp; onRetry != null)</code> uses the equality special rule. <code>state</code> is typed <code>ConnectionState</code>, so <code>.error</code> resolves to <code>ConnectionState.error</code>. The switch inside <code>_buildIcon()</code> switches on <code>state</code> (typed <code>ConnectionState</code>), providing context for all case patterns.</p> <p>Each <code>.connecting</code>, <code>.connected</code>, <code>.disconnected</code>, <code>.limited</code>, and <code>.error</code> resolves to the corresponding enum value. The <code>_textColor()</code> method's switch has the same structure.</p> <h3 id="heading-the-screen">The Screen</h3> <pre><code class="language-dart">// lib/screens/network_demo_screen.dart import 'package:flutter/material.dart'; import '../models/connection_state.dart'; import '../models/network_config.dart'; import '../widgets/connection_status_widget.dart'; class NetworkDemoScreen extends StatefulWidget { const NetworkDemoScreen({super.key}); @override State&lt;NetworkDemoScreen&gt; createState() =&gt; _NetworkDemoScreenState(); } class _NetworkDemoScreenState extends State&lt;NetworkDemoScreen&gt; { ConnectionState _state = .connecting; // enum shorthand on field NetworkConfig _config = .standard(); // named constructor shorthand void _simulateConnection() { setState(() =&gt; _state = .connected); // enum shorthand in closure } void _simulateError() { setState(() =&gt; _state = .error); // enum shorthand in closure } void _simulateDisconnect() { setState(() =&gt; _state = .disconnected); // enum shorthand in closure } void _resetToConnecting() { setState(() { _state = .connecting; // enum shorthand in block _config = .debug(); // named constructor shorthand }); } @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text('Network Status Demo'), centerTitle: true, ), body: Column( mainAxisAlignment: .center, // enum shorthand on parameter crossAxisAlignment: .stretch, children: [ ConnectionStatusWidget( state: _state, onRetry: _state == .error ? _resetToConnecting : null, ), const Divider(), Padding( padding: .all(16), // named constructor shorthand child: Column( mainAxisSize: .min, children: [ Text( 'Simulate state change:', style: TextStyle(fontWeight: .bold), ), const SizedBox(height: 12), Row( mainAxisAlignment: .spaceEvenly, children: [ ElevatedButton( onPressed: _simulateConnection, child: const Text('Connect'), ), ElevatedButton( onPressed: _simulateDisconnect, child: const Text('Disconnect'), ), ElevatedButton( onPressed: _simulateError, child: const Text('Error'), ), ], ), const SizedBox(height: 8), TextButton( onPressed: _resetToConnecting, child: const Text('Reset'), ), ], ), ), Padding( padding: .symmetric(horizontal: 16), // named constructor shorthand child: Card( child: ListTile( title: const Text('Config'), subtitle: Text( 'Timeout: ${_config.timeout.inSeconds}s | ' 'Retries: ${_config.maxRetries}', ), trailing: Switch( value: _config.showDetailedErrors, onChanged: null, ), ), ), ), ], ), ); } } </code></pre> <p><code>ConnectionState _state = .connecting</code> declares the field with an explicit type <code>ConnectionState</code>, which provides the context for <code>.connecting</code>. This is one of the most impactful uses: initializing a stateful field in a widget's state class is now a one-read expression.</p> <p><code>NetworkConfig _config = .standard()</code> calls the static factory method on <code>NetworkConfig</code> using the field's declared type as context. <code>setState(() =&gt; _state = .connected)</code> uses <code>.connected</code> inside a lambda where <code>_state</code> is already declared as <code>ConnectionState</code>. The assignment target <code>_state</code> provides the context type.</p> <p><code>_state == .error ? _resetToConnecting : null</code> uses the equality special rule: <code>_state</code> is <code>ConnectionState</code>, so <code>.error</code> resolves to <code>ConnectionState.error</code>. <code>mainAxisAlignment: .center</code>, <code>crossAxisAlignment: .stretch</code>, <code>mainAxisSize: .min</code>, <code>fontWeight: .bold</code>, <code>mainAxisAlignment: .spaceEvenly</code> all resolve from their respective parameter types. <code>padding: .all(16)</code> and <code>padding: .symmetric(horizontal: 16)</code> resolve from the <code>EdgeInsets</code> type of <code>Padding.padding</code>.</p> <h3 id="heading-the-entry-point">The Entry Point</h3> <pre><code class="language-dart">// lib/main.dart import 'package:flutter/material.dart'; import 'screens/network_demo_screen.dart'; void main() { runApp(const MyApp()); } class MyApp extends StatelessWidget { const MyApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( title: 'Dot Shorthand Demo', debugShowCheckedModeBanner: false, theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue), useMaterial3: true, ), home: const NetworkDemoScreen(), ); } } </code></pre> <p>This is a standard Flutter entry point. The dot shorthand feature doesn't change how apps are wired up. Every shorthand in this codebase resolves at compile time, producing exactly the same binary as if you had written the full <code>TypeName.member</code> form throughout.</p> <h2 id="heading-conclusion">Conclusion</h2> <p>Dot shorthands aren't a dramatic language redesign. They're a precision quality-of-life improvement that removes a specific, well-defined category of noise from Dart and Flutter code: the repetition of a type name that the compiler already knows.</p> <p>In the places where they work, they work cleanly and unambiguously, and the resulting code communicates meaning without the visual overhead of prefix repetition.</p> <p>The feature's power is proportional to how much you use enums, static factories, named constructors, and switch statements. If you write Flutter widgets, you use all of these constantly. That's why the Flutter community's reaction to dot shorthands was strong and positive: these are the patterns Flutter developers write every day, and the noise reduction is immediately visible from the first widget you edit.</p> <p>The mental model to keep is the single rule at the center of the feature: a dot shorthand works only where the compiler already knows the expected type. Once that rule is clear, the feature becomes predictable.</p> <p>You'll know instantly whether a shorthand is valid at any given position: look for the context type. If there is one (from a variable declaration, a parameter type, a return type, or the left side of an equality comparison), the shorthand works. If there's not (from <code>var</code>, <code>dynamic</code>, or an unannotated expression), it does not.</p> <p>The adoption path for an existing codebase is straightforward. Update the SDK constraint in <code>pubspec.yaml</code>. Enable the <code>prefer-shorthands-with-enums</code> lint rule from DCM if your team uses it. Let the linter find the highest-value opportunities. Migrate switch statements and widget parameter enums first, where the context is clearest and the visual gain is highest. Work outward from there to named constructors and static methods where the type name adds genuinely redundant information.</p> <p>The feature is available now in Dart 3.10, Flutter 3.38, and DartPad. The existing code you write using the full form continues to compile without change. Adoption is fully incremental. There's no migration deadline, no deprecation warning, and no behavioral difference. It's simply a cleaner way to say what your code was already saying.</p> <h2 id="heading-references">References</h2> <ul> <li><p><strong>Dart Dot Shorthands Language Reference:</strong> The official Dart documentation page for dot shorthands, covering the complete syntax, all valid use cases, the <code>==</code> and <code>!=</code> special rules, nullable types, and <code>FutureOr</code>. The authoritative reference for everything in this handbook.<br><a href="https://dart.dev/language/dot-shorthands">https://dart.dev/language/dot-shorthands</a></p> </li> <li><p><strong>Dart 3.10 Announcement:</strong> The official Dart blog post announcing Dart 3.10 and the dot shorthand feature, with the motivation, the headline examples, and links to the full documentation.<br><a href="https://blog.dart.dev/announcing-dart-3-10-ea8b952b6088">https://blog.dart.dev/announcing-dart-3-10-ea8b952b6088</a></p> </li> <li><p><strong>Dart Language Evolution:</strong> The complete Dart language version history, listing every feature introduced per version. Useful for verifying which language version a feature requires. <a href="https://dart.dev/resources/language/evolution">https://dart.dev/resources/language/evolution</a></p> </li> <li><p><strong>Dot Shorthands Feature Specification:</strong> The formal language specification for dot shorthands on the Dart language GitHub repository. Covers the grammar changes, the type inference rules, and the reasoning behind each design decision including the <code>FutureOr</code> handling and the <code>==</code> special rule.<br><a href="https://github.com/dart-lang/language/blob/main/accepted/3.10/dot-shorthands/feature-specification.md">https://github.com/dart-lang/language/blob/main/accepted/3.10/dot-shorthands/feature-specification.md</a></p> </li> </ul>