---
title: Known limitations
description: Current limitations in Curb's formatting output and what to expect on first adoption.
url: https://docs-v3-preview.elastic.dev/known-limitations
---

# Known limitations
## Multi-line trivia keeps source line endings

Curb emits multi-line trivia — doc comments, verbatim string literals — as a raw source span,
so their internal newlines survive unchanged while the breaks Curb emits itself use the configured
line ending. The result is a file with mixed line endings.
This means `dotnet format` disagrees with Curb's output on any file containing doc comments
whose source line endings differ from the configured `end_of_line`. It is the most common source of
fixed-point failures in the [twelve-repository comparison](https://docs-v3-preview.elastic.dev/benchmarks).

## Expression-body conversions do not compose in one pass

With both `csharp_style_expression_bodied_properties = true` and
`csharp_style_expression_bodied_accessors = true`, the two conversions can produce different output
on consecutive passes:
```csharp
public int Count { get { throw new NotImplementedException(); } }  
public int Count { get => throw new NotImplementedException(); }   
public int Count => throw new NotImplementedException();           
```

The accessor-level conversion fires on run 1. The property-level conversion only recognises an
accessor list that already has an arrow getter, so it fires on run 2. Two rules that should compose
in one pass currently do not.

## Anchor columns feed back into the next run

In certain initializer patterns, Curb's output indentation can change between consecutive
passes. An initializer anchors to the indentation of the line it starts on; when Curb's own
output moves that line, the next run anchors somewhere else. The same applies to comment alignment in
some cases. It is the anchor mechanism being unstable under its own output on real code.