If you've written Flutter code for more than a month, you've likely written this line hundreds of times:
mainAxisAlignment: MainAxisAlignment.center,
crossAxisAlignment: CrossAxisAlignment.start,
mainAxisSize: MainAxisSize.min,
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: MainAxisAlignment.center. CrossAxisAlignment.start. MainAxisSize.min. Three words to say one thing, when the surrounding context has already made the type completely obvious.
This isn't an isolated friction. It shows up everywhere in Dart and Flutter. You write Colors.blue on a parameter typed as Color. You write BorderRadius.circular(8) on a parameter typed as BorderRadius. You write Duration.zero on a field typed as Duration. You write TextAlign.center on a parameter typed as TextAlign.
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.
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, .center instead of MainAxisAlignment.center. .circular(8) instead of BorderRadius.circular(8). .zero instead of Duration.zero. The type name you were spelling out is now optional, because the compiler can and will infer it.
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.
The first time you enable it in a real codebase, your Column and Row parameters become noticeably cleaner. Your switch statements read more like prose. Your code says what it means without the prefix weight.
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.
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.
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.
Table of Contents
Prerequisites
What Are Dot Shorthands?
Starting with a Direct Analogy
The Technical Definition
The Problem: Life Before Dot Shorthands
The Repetition Pattern
The Switch Statement Problem
The One Rule That Governs Everything: Context
- The Single Mental Model You Need
Enums: The Primary Use Case
Why Enums Benefit Most
Assignments
Flutter Widget Parameters
Enhanced Enums
Inside Functions with Enum Return Types
Static Fields and Constants
Static Constants
Static Fields on Built-In Dart Types
Static Methods
Calling Static Methods with Shorthands
In Function Arguments
Constructors and Named Constructors
Named Constructors
In Widget Constructors
The .new Shorthand
Invoking the Default Constructor
When .new Is Most Useful
Chaining After a Shorthand
Chaining Instance Methods
Why This Matters
Equality Operators: The Special Rule
How == and != Work with Dot Shorthands
Equality in Conditional Expressions
What Does Not Work
Switch Statements and Pattern Matching
Switch on Enums
Switch Expressions
Pattern Matching in Switch
Nullable Types
Accessing Members of T Through T?
Nullable Variable Assignments
What Nullable Context Does Not Grant
FutureOr and Async Returns
Returning Values from Async Functions
FutureOr in Non-Async Contexts
Dot Shorthands in Flutter Widget Trees
- The Transformation in Practice
Advanced Concepts
Where the Inference Does Not Kick In
Nested Shorthands
Dot Shorthands with Extension Types
Linter Support
Best Practices
Start With Enums and Switch Statements
Always Keep the Full Form When Type Is Genuinely Unclear
Be Consistent Across a File or Team
Update Your pubspec.yaml Before Using Any Shorthands
When to Use Dot Shorthands and When Not To
Where Dot Shorthands Are Clearly the Right Choice
Where to Prefer the Full Form
Common Mistakes
Using var Instead of an Explicit Type
Forgetting to Update the SDK Constraint
Assuming Shorthands Work Inside Generic Type Arguments
Over-Using Shorthands Where Type Context Is Thin
Mini End-to-End Example
The Enum and State Model
The Config Model
The Status Widget
The Screen
The Entry Point
Conclusion
References
Prerequisites
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.
Dart fundamentals: You should understand classes, enums, static members, constructors, and named constructors. If you know the difference between ClassName.member and instance.member, and you understand what static means on a field or method, you're ready.
Flutter widget basics: You should be comfortable writing Column, Row, Container, 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.
Dart's type system: 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.
Dart SDK 3.10 and Flutter 3.38 or higher: Dot shorthands are a language-version-gated feature. Your project must opt in to Dart 3.10. Update the SDK constraint in your pubspec.yaml:
environment:
sdk: ^3.10.0
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.
Without this change, using .center or .zero will produce a compile error telling you that dot shorthand requires language version 3.10 or later. If you're using Flutter, running flutter upgrade and updating the SDK constraint is all that's required.
DartPad for experimentation: You can test the examples in this guide interactively at https://dartpad.dev. DartPad supports Dart 3.10 and is the fastest way to test whether a particular shorthand works in a given context.
What Are Dot Shorthands?
Starting with a Direct Analogy
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.
That's exactly what dot shorthands do. When Dart already knows from the surrounding context that a value must be of type MainAxisAlignment, you can write just .center instead of MainAxisAlignment.center. The type label is already there. The shorthand lets you write just the value.
The Technical Definition
A dot shorthand is an expression that begins with a leading dot (.) 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 T, writing .member is treated as T.member. Writing .new(args) is treated as T.new(args) (the unnamed constructor). Writing .namedConstructor(args) is treated as T.namedConstructor(args).
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:
The declared type of a variable being assigned to
The declared type of a function parameter being passed a value
The declared return type of a function when a value is being returned
The static type of the left-hand side of a
==or!=comparison (special rule)The declared type of a field in an initializer
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.
The Problem: Life Before Dot Shorthands
The Repetition Pattern
Open any Flutter project and look at the widget tree of a non-trivial screen. You'll see something like this:
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'),
),
],
)
Count the enum type name repetitions in that code. MainAxisAlignment appears twice. CrossAxisAlignment appears twice. The words MainAxisAlignment, CrossAxisAlignment, TextAlign, TextOverflow, Alignment, BorderRadius, Colors are all written out in full.
And for each one, the type is already declared on the parameter: mainAxisAlignment takes a MainAxisAlignment, crossAxisAlignment takes a CrossAxisAlignment, and so on. The parameter name itself carries the type information. Yet the full type name was required before the dot.
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."
The Switch Statement Problem
Enum-driven switch statements had the same issue:
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);
}
The variable status is already typed as NetworkStatus. Every case therefore operates on a NetworkStatus value. Writing NetworkStatus.connecting, NetworkStatus.connected, NetworkStatus.disconnected, and NetworkStatus.error in every case is pure repetition. The type name adds no information because it's already known from the switch target.
These patterns were unavoidable before Dart 3.10. They were just the cost of the language's verbosity in static contexts.
The One Rule That Governs Everything: Context
The Single Mental Model You Need
Before diving into specific use cases, internalize this single rule, because once you have it, every dot shorthand example in the language becomes obvious:
A dot shorthand works only where the compiler already knows the expected type.
That's the complete rule. Everything else is a consequence of it.
If the compiler knows the type, .member resolves to TypeName.member. 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.
Let's see what this means concretely:
// 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
NetworkStatus currentStatus = .connecting works because the explicit type annotation NetworkStatus on the variable declaration gives the compiler all it needs.
var x = .connecting fails because var 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.
update(.connected) works because the function's parameter type NetworkStatus is the context.
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.
Enums: The Primary Use Case
Why Enums Benefit Most
Enums are the primary and most recommended use case for dot shorthands for two reasons.
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.
Assignments
enum Status { idle, loading, success, error }
// Before Dart 3.10
Status currentStatus = Status.idle;
// With dot shorthands (Dart 3.10+)
Status currentStatus = .idle;
The variable declaration Status currentStatus provides the context type. When the compiler reaches the right-hand side and sees .idle, it looks up the context type (Status), checks that Status has a member named idle, and resolves the expression to Status.idle. The resulting compiled code is identical to the before version. There's no runtime difference, only a syntactic one.
Flutter Widget Parameters
// 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,
)
The Column widget's constructor declares its parameter types explicitly: mainAxisAlignment is MainAxisAlignment, crossAxisAlignment is CrossAxisAlignment, mainAxisSize is MainAxisSize. Each parameter declaration is the context type for the argument passed to it. When the compiler sees .center in the mainAxisAlignment position, the context type is MainAxisAlignment, so .center becomes MainAxisAlignment.center. Each shorthand resolves independently using its own parameter's declared type.
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.
Enhanced Enums
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:
enum Priority {
low(1),
medium(5),
high(10);
final int weight;
const Priority(this.weight);
static Priority fromWeight(int w) {
if (w <= 3) return low;
if (w <= 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);
Priority taskPriority = .high uses the variable's declared type as context. .high resolves to Priority.high. Priority resolved = .fromWeight(8) calls the static fromWeight method on Priority without spelling out the type name. Both work because the variable type provides the context.
Inside Functions with Enum Return Types
Priority getDefaultPriority() {
return .medium; // return type provides context: Priority
}
When the declared return type of a function is an enum type, the return statement's value has that type as its context. .medium resolves to Priority.medium because the function's return type is Priority. The same applies to any function, method, or getter whose return type is explicit.
Static Fields and Constants
Static Constants
Static constants, especially sentinel values like Duration.zero, EdgeInsets.zero, and Offset.zero, are common throughout Flutter and Dart. Dot shorthands make them noticeably cleaner:
// 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;
In each case, the variable's declared type (Duration, EdgeInsets, Offset) is the context. .zero resolves to the appropriate type's static zero constant in each case.
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.
Static Fields on Built-In Dart Types
Dart's built-in types also expose static fields, and they work equally well:
// 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
Duration animationDuration = .zero resolves .zero as Duration.zero from the variable's type. double maxWidth = .infinity resolves .infinity as double.infinity. The second example also shows the beginnings of chaining, which is covered in its own section.
Static Methods
Calling Static Methods with Shorthands
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:
// 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();
int port = .parse('8080') resolves to int.parse('8080') because the variable's declared type is int, and int has a static method named parse that accepts a String and returns an int. double ratio = .parse('1.618') resolves to double.parse('1.618') using the same mechanism. DateTime now = .now() resolves to DateTime.now() from the DateTime context.
The method's return type must be compatible with the context type. If int.parse returned a String, 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.
In Function Arguments
void configure({required Duration timeout, required int retryCount}) {}
configure(
timeout: .zero, // Duration context -> Duration.zero
retryCount: .parse('3'), // int context -> int.parse('3')
);
Each named argument's declared parameter type is the context for the argument value. timeout is declared as Duration, so .zero resolves to Duration.zero. retryCount is declared as int, so .parse('3') resolves to int.parse('3'). Each argument's shorthand resolves independently using its own parameter's type.
Constructors and Named Constructors
Named Constructors
Named constructors are one of Dart's most idiomatic patterns. They exist on EdgeInsets, BorderRadius, Color, TextStyle, Duration, and dozens of other types you use in every Flutter app. Dot shorthands work with all of them:
// 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
EdgeInsets padding = .all(16) works because EdgeInsets is the context type and .all(16) resolves to EdgeInsets.all(16), which is a named constructor. BorderRadius radius = .circular(8) follows the same pattern.
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.
In Widget Constructors
Named constructors shine in widget parameters, which is where most Flutter developers will use them most:
// 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'),
),
)
padding: .symmetric(horizontal: 16, vertical: 8) resolves .symmetric(...) as EdgeInsets.symmetric(...) because the padding parameter of Padding is declared as EdgeInsets. borderRadius: .circular(12) resolves as BorderRadius.circular(12) because the borderRadius field of BoxDecoration is typed as BorderRadius?. border: .all(color: Colors.grey, width: 1) resolves as Border.all(...) because the border field of BoxDecoration is typed as BoxBorder?, which Border implements.
The shorthand resolution checks the static type of the member, not just the exact declared type.
The .new Shorthand
Invoking the Default Constructor
Dart's ClassName.new is the named reference to the unnamed default constructor. Dot shorthands support .new(args) as a shorthand for calling the default constructor:
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);
.new('https://api.example.com', 30) resolves to AppConfig.new('https://api.example.com', 30), which is the same as calling AppConfig('https://api.example.com', 30). The context type AppConfig from the variable declaration drives the resolution.
When .new Is Most Useful
The .new 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.
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:
// A list of items where each item is constructed in place
List<AppConfig> configs = [
.new('https://api.example.com', 30),
.new('https://staging.example.com', 60),
.new('https://dev.example.com', 120),
];
List<AppConfig> configs provides the context type through the list's element type AppConfig. Each .new(...) inside the list literal resolves to AppConfig(...). In a list with many similar constructor calls, the shorthand removes the repetitive type prefix that would otherwise appear on every item.
Chaining After a Shorthand
Chaining Instance Methods
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:
// 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();
int value = .parse(' 42 ').abs() resolves .parse(' 42 ') as int.parse(' 42 '), which returns an int. Then .abs() is called on that int instance. The result is an int, which matches the variable's declared type.
The shorthand only applies to the leading static access. The rest of the chain is ordinary instance member access. String statusLabel = .loading.name.toUpperCase() demonstrates chaining on an enum value. The context type for the shorthand resolution comes from the enum (here assumed to be a Status or similar), .name is a built-in property on every enum value that returns the value's name as a String, and .toUpperCase() is an instance method on String.
Why This Matters
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 .member is the shorthand, everything after it is a normal instance access chain.
// 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
Color primary = .fromARGB(255, 66, 133, 244) uses the Color context to resolve the shorthand. double alpha = .fromARGB(255, 66, 133, 244).opacity has double as the context type, not Color. This means .fromARGB would need to resolve to a static method on double that exists, which it does not.
This particular example would fail. The context type governs the leading access, so the context for the leading shorthand is double, not Color. This is a subtle point: when chaining, make sure the context type at the expression position matches the type you're targeting.
Equality Operators: The Special Rule
How == and != Work with Dot Shorthands
The == and != 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 == or != expression, the context type is derived from the static type of the left-hand side, not from any surrounding variable or parameter:
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.');
}
myColor == .green works because myColor is declared as Color, making Color the context for the right-hand side .green. The compiler resolves .green as Color.green before performing the equality comparison.
This special rule exists because == expressions don't have a surrounding context type the way variable assignments do. The left-hand side is used instead.
Equality in Conditional Expressions
Color selectedColor = Color.red;
bool condition = true;
Color inferredColor = condition ? .red : .blue;
Color inferredColor = condition ? .red : .blue resolves both .red and .blue as Color values. The context type for a ternary expression comes from the assignment target's type, which is Color. Both branches of the ternary receive the same context type, so both shorthands resolve correctly.
What Does Not Work
// 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
var isMatch = someValue == .green fails when someValue'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.
Switch Statements and Pattern Matching
Switch on Enums
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:
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();
}
state is declared as AppState, making AppState the context type for every case in the switch. Each .loading, .loaded, .error, and .empty resolves to the corresponding AppState value. The switch is exhaustive – checking works the same way. The compiler still verifies that all enum cases are covered.
Switch Expressions
Dart's switch expressions (the expression form that returns a value) work identically:
Widget content = switch (state) {
.loading => const CircularProgressIndicator(),
.loaded => const ContentWidget(),
.error => const ErrorWidget(),
.empty => const EmptyStateWidget(),
};
switch (state) where state is AppState provides AppState as the context for each pattern on the left side of the =>. Each .loading, .loaded, .error, and .empty resolves to the corresponding AppState value. The right side of each => arrow isn't affected by the switch context; each => branch is a normal expression.
Pattern Matching in Switch
void handleResult(Result result) {
switch (result) {
case .success when result.value > 0:
print('Positive success: ${result.value}');
case .success:
print('Non-positive success');
case .failure:
print('Failed: ${result.error}');
}
}
Guard clauses (when) work naturally alongside dot shorthands. .success when result.value > 0 is a case pattern for the enum value Result.success with an additional guard condition. The shorthand resolves to the enum value for matching purposes, and the guard is evaluated separately.
Nullable Types
Accessing Members of T Through T?
When a variable or parameter has a nullable type T?, you can still use dot shorthands to access static members of the underlying type T. The Dart specification explicitly allows this:
// 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?
updateStatus(.loading) works because the parameter type Status? provides a context of Status?, and the dot shorthand rules allow accessing members of Status in a Status? context. The value .loading resolves to Status.loading, which is a non-null Status, and non-null values are always valid in a nullable position.
Nullable Variable Assignments
Status? maybeStatus = .error; // Assigns Status.error to a Status? variable
Status? nothing = null; // Still works; null is valid for Status?
Status? maybeStatus = .error resolves .error as Status.error (from the Status? 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.
What Nullable Context Does Not Grant
The nullable context allows accessing members of T, but not members of Null. Null has no useful static members for this purpose, and the feature doesn't expose them:
// 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
Duration? elapsed = .zero resolves .zero as Duration.zero from the Duration? context. The nullable wrapper is transparent for the purposes of static member lookup.
FutureOr and Async Returns
Returning Values from Async Functions
Inside an async function, the effective return type of every return statement is FutureOr<T> where T is the declared return type. The dot shorthand specification explicitly handles this case by allowing T's static members to be accessed in a FutureOr<T> context:
Future<Status> fetchStatus() async {
// The function's declared return type is Future<Status>.
// Inside an async function, return accepts a FutureOr<Status>.
// Dot shorthand resolves .loaded as Status.loaded.
return .loaded;
}
return .loaded inside a Future<Status> async function works because the async function's return context is FutureOr<Status>, and the dot shorthand rules allow accessing Status members through a FutureOr<Status> context.
The Dart team specifically decided to support this case because returning bare values from async functions is extremely common, and requiring Status.loaded when the function's return type already says Status was seen as unnecessary verbosity.
FutureOr in Non-Async Contexts
FutureOr<Duration> getDelay() {
// Can return either a Duration or a Future<Duration>
return .zero; // Resolves to Duration.zero
}
return .zero in a function returning FutureOr<Duration> resolves .zero as Duration.zero because the FutureOr<Duration> context grants access to Duration's members. The returned value is a synchronous Duration, which is a valid FutureOr<Duration>.
The Transformation in Practice
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.
Here's a realistic profile card widget, before and after:
// 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,
),
],
),
),
);
}
}
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.
Now the same thing with dot shorthands:
// 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,
),
],
),
),
);
}
}
padding: .all(16) resolves to EdgeInsets.all(16) because Padding.padding is typed EdgeInsets. mainAxisAlignment: .start resolves to MainAxisAlignment.start because Row.mainAxisAlignment is typed MainAxisAlignment. crossAxisAlignment: .center resolves to CrossAxisAlignment.center. fontWeight: .bold resolves to FontWeight.bold because TextStyle.fontWeight is FontWeight?. mainAxisSize: .min resolves to MainAxisSize.min. overflow: .ellipsis resolves to TextOverflow.ellipsis.
Each shorthand is driven by the declaring parameter's type.
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.
Advanced Concepts
Where the Inference Does Not Kick In
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:
// 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<Status> 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
var status = .loading fails because var 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.
var items = [.loading, .error] fails for the same reason: the list's element type would come from its contents, but the contents need the element type.
List<Status> items = [.loading, .error] works because the explicit type annotation gives the compiler the Status context before it evaluates the list elements.
But dynamic value = .loading fails because dynamic bypasses the type system and doesn't provide a usable static context type for member lookup.
Nested Shorthands
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:
// 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,
),
);
This works. Each shorthand resolves independently: .circular(8) from the BorderRadius? context of boxDecoration.borderRadius, and .all(...) from the BoxBorder? context of boxDecoration.border. They aren't nested in the sense of depending on each other.
A truly nested shorthand would be using a shorthand inside the arguments of another shorthand's call:
// Attempting to use a shorthand inside another shorthand's arguments
EdgeInsets padding = .fromLTRB(
.zero.left, // ERROR: .zero has no context here
8, 8, 8,
);
.zero.left fails because .zero inside the argument to .fromLTRB doesn't have an established context type. The DCM linter provides an avoid-nested-shorthands rule that flags these cases. The fix is always to be explicit in the inner position where context is unclear:
EdgeInsets padding = .fromLTRB(
EdgeInsets.zero.left, // Explicit: fine
8, 8, 8,
);
Dot Shorthands with Extension Types
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:
extension type Milliseconds(int value) {
static Milliseconds get zero => Milliseconds(0);
static Milliseconds fromSeconds(int seconds) => Milliseconds(seconds * 1000);
}
Milliseconds delay = .zero; // Milliseconds.zero
Milliseconds timeout = .fromSeconds(5); // Milliseconds.fromSeconds(5)
Milliseconds delay = .zero resolves .zero as Milliseconds.zero from the variable's declared type. Milliseconds timeout = .fromSeconds(5) resolves the static factory method on Milliseconds.
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.
Linter Support
The DCM (Dart Code Metrics) tool provides four lint rules specifically for dot shorthands, which help enforce consistent adoption:
# 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
prefer-shorthands-with-enums flags any enum value access where the type name could be dropped because context makes it clear. prefer-shorthands-with-static-fields does the same for static field accesses. prefer-returning-shorthands flags return statements where the type name could be omitted. prefer-shorthands-with-constructors with an entries list flags specific classes where named constructor calls could use shorthands. avoid-nested-shorthands flags the problematic nested cases described above.
Enabling these rules gradually (starting with prefer-shorthands-with-enums, the most impactful) is the recommended migration strategy for an existing codebase.
Best Practices
Start With Enums and Switch Statements
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.
Always Keep the Full Form When Type Is Genuinely Unclear
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.
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.
// 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
alignment: .centerLeft is clear because the parameter name alignment strongly implies Alignment. Color.fromARGB(...) is more readable than .fromARGB(...) because fromARGB as a method name doesn't clearly signal which type it comes from, and Color in front of it removes any ambiguity instantly.
Be Consistent Across a File or Team
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.
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.
Update Your pubspec.yaml Before Using Any Shorthands
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.
Update the constraint before adopting the syntax:
environment:
sdk: ^3.10.0
sdk: ^3.10.0 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 pubspec.yaml needs its own updated constraint for that package to use dot shorthands.
When to Use Dot Shorthands and When Not To
Where Dot Shorthands Are Clearly the Right Choice
Enum values in Flutter widget parameters are the canonical use case. mainAxisAlignment: .center, crossAxisAlignment: .start, mainAxisSize: .min, textAlign: .left are all unambiguous, save significant horizontal space in already-deep widget trees, and make the code read more naturally.
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.
Well-known sentinels like .zero, .empty, .none on types where that member is universally understood are also excellent candidates. Duration timeout = .zero is clearer than Duration timeout = Duration.zero because the context gives you the type and zero is a universally understood sentinel.
Where to Prefer the Full Form
Any constructor or static method call where the method name doesn't clearly signal the type is a case for the full form. .fromARGB(255, 66, 133, 244) is not as self-explanatory as Color.fromARGB(255, 66, 133, 244). The explicit type name acts as documentation.
Any context where a new developer might not know what type they're looking at deserves the full form. If a parameter is named config and the type is a custom class ServerConfig, writing .defaults() is less clear than ServerConfig.defaults() because config is a vague name and the shorthand hides the class being instantiated.
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.
Common Mistakes
Using var Instead of an Explicit Type
The most common beginner mistake with dot shorthands is trying to use them with var:
// ERROR: var cannot provide a context type
var status = .loading;
// CORRECT: explicit type annotation provides the context
Status status = .loading;
var status = .loading looks like it should work because var eventually gets inferred as Status if you assign a Status value. But type inference for var works by looking at the right-hand side first, and the right-hand side (the shorthand) needs the left-hand type to resolve.
var 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.
Forgetting to Update the SDK Constraint
# 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
Attempting to use .loading 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 sdk constraint in pubspec.yaml, then run flutter pub get or dart pub get. No code changes are needed beyond the pubspec.yaml update to enable the feature.
Assuming Shorthands Work Inside Generic Type Arguments
// ERROR: Type arguments do not provide a shorthand context
List<.center> items; // Meaningless and invalid
Map<String, .loading> cache; // Invalid
Type argument positions (the <T> in generic types) aren't expression positions. They can't contain dot shorthands.
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.
Over-Using Shorthands Where Type Context Is Thin
// 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);
.fromJSON(data) is a shorthand that technically works if SomeConfig is the context type, but fromJSON 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 SomeConfig explicitly in the constructor call makes it immediately readable. Not every valid shorthand is an improvement.
Mini End-to-End Example
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.
The feature is a network status indicator widget for an app that shows different UI states based on connection status.
The Enum and State Model
// lib/models/connection_state.dart
enum ConnectionState {
connecting,
connected,
disconnected,
limited,
error;
bool get isActive => this == .connected || this == .limited;
bool get isTerminal => this == .disconnected || this == .error;
static ConnectionState fromCode(int code) {
return switch (code) {
0 => .connecting,
1 => .connected,
2 => .limited,
3 => .disconnected,
_ => .error,
};
}
String get label => switch (this) {
.connecting => 'Connecting...',
.connected => 'Connected',
.disconnected => 'Disconnected',
.limited => 'Limited Connection',
.error => 'Connection Error',
};
}
bool get isActive => this == .connected || this == .limited uses the == special rule. this is a ConnectionState instance, so this == .connected resolves .connected as ConnectionState.connected from the static type of the left-hand side this.
static ConnectionState fromCode(int code) is a static factory method on the enum. Inside the switch expression, the return type ConnectionState provides context for each => result. .connecting resolves to ConnectionState.connecting, .connected to ConnectionState.connected, and so on.
The _ wildcard case returns .error, which also resolves to ConnectionState.error. String get label uses a switch expression on this, which is typed ConnectionState, providing context for the case patterns. Each .connecting, .connected, .disconnected, .limited, and .error resolves to the corresponding enum value.
The Config Model
// 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 -> Duration.zero
maxRetries: .parse('3'), // int context -> int.parse('3')
showDetailedErrors: false,
);
}
factory NetworkConfig.debug() {
return NetworkConfig(
timeout: .fromSeconds(60), // Duration context -> Duration.fromSeconds(60)
maxRetries: .parse('10'), // int context -> int.parse('10')
showDetailedErrors: true,
);
}
}
timeout: .zero uses the field's declared type Duration as context. .zero resolves to Duration.zero. maxRetries: .parse('3') uses the field's declared type int as context. .parse('3') resolves to int.parse('3'), which returns an int. timeout: .fromSeconds(60) resolves to Duration.fromSeconds(60), a named constructor on Duration.
These are simple but realistic patterns: factory constructors that use static methods and sentinels from other types, now without spelling out those types.
The Status Widget
// 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 && onRetry != null)
TextButton(
onPressed: onRetry,
child: const Text('Retry'),
),
],
),
);
}
Widget _buildIcon() {
final (IconData icon, Color color) = switch (state) {
.connecting => (Icons.sync, Colors.orange),
.connected => (Icons.wifi, Colors.green),
.disconnected => (Icons.wifi_off, Colors.grey),
.limited => (Icons.signal_wifi_4_bar_lock, Colors.amber),
.error => (Icons.error_outline, Colors.red),
};
return Icon(icon, color: color, size: 18);
}
Color _textColor() => switch (state) {
.connected => Colors.green,
.error => Colors.red,
.disconnected => Colors.grey,
_ => Colors.orange,
};
}
duration: .fromMilliseconds(300) resolves to Duration.fromMilliseconds(300) because AnimatedSwitcher.duration is typed Duration. padding: .symmetric(horizontal: 16, vertical: 12) resolves to EdgeInsets.symmetric(...) because Padding.padding is typed EdgeInsets. mainAxisAlignment: .spaceBetween resolves to MainAxisAlignment.spaceBetween. crossAxisAlignment: .center resolves to CrossAxisAlignment.center. mainAxisSize: .min resolves to MainAxisSize.min. fontWeight: .w500 resolves to FontWeight.w500 because TextStyle.fontWeight is FontWeight?.
if (state == .error && onRetry != null) uses the equality special rule. state is typed ConnectionState, so .error resolves to ConnectionState.error. The switch inside _buildIcon() switches on state (typed ConnectionState), providing context for all case patterns.
Each .connecting, .connected, .disconnected, .limited, and .error resolves to the corresponding enum value. The _textColor() method's switch has the same structure.
The Screen
// 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<NetworkDemoScreen> createState() => _NetworkDemoScreenState();
}
class _NetworkDemoScreenState extends State<NetworkDemoScreen> {
ConnectionState _state = .connecting; // enum shorthand on field
NetworkConfig _config = .standard(); // named constructor shorthand
void _simulateConnection() {
setState(() => _state = .connected); // enum shorthand in closure
}
void _simulateError() {
setState(() => _state = .error); // enum shorthand in closure
}
void _simulateDisconnect() {
setState(() => _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,
),
),
),
),
],
),
);
}
}
ConnectionState _state = .connecting declares the field with an explicit type ConnectionState, which provides the context for .connecting. This is one of the most impactful uses: initializing a stateful field in a widget's state class is now a one-read expression.
NetworkConfig _config = .standard() calls the static factory method on NetworkConfig using the field's declared type as context. setState(() => _state = .connected) uses .connected inside a lambda where _state is already declared as ConnectionState. The assignment target _state provides the context type.
_state == .error ? _resetToConnecting : null uses the equality special rule: _state is ConnectionState, so .error resolves to ConnectionState.error. mainAxisAlignment: .center, crossAxisAlignment: .stretch, mainAxisSize: .min, fontWeight: .bold, mainAxisAlignment: .spaceEvenly all resolve from their respective parameter types. padding: .all(16) and padding: .symmetric(horizontal: 16) resolve from the EdgeInsets type of Padding.padding.
The Entry Point
// 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(),
);
}
}
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 TypeName.member form throughout.
Conclusion
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.
In the places where they work, they work cleanly and unambiguously, and the resulting code communicates meaning without the visual overhead of prefix repetition.
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.
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.
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 var, dynamic, or an unannotated expression), it does not.
The adoption path for an existing codebase is straightforward. Update the SDK constraint in pubspec.yaml. Enable the prefer-shorthands-with-enums 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.
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.
References
Dart Dot Shorthands Language Reference: The official Dart documentation page for dot shorthands, covering the complete syntax, all valid use cases, the
==and!=special rules, nullable types, andFutureOr. The authoritative reference for everything in this handbook.
https://dart.dev/language/dot-shorthandsDart 3.10 Announcement: 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.
https://blog.dart.dev/announcing-dart-3-10-ea8b952b6088Dart Language Evolution: The complete Dart language version history, listing every feature introduced per version. Useful for verifying which language version a feature requires. https://dart.dev/resources/language/evolution
Dot Shorthands Feature Specification: 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
FutureOrhandling and the==special rule.
https://github.com/dart-lang/language/blob/main/accepted/3.10/dot-shorthands/feature-specification.md
Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started