Skip to content

LIST-EXTENDED, part 1: response data item types - #716

Open
soywod wants to merge 1 commit into
duesee:mainfrom
soywod:types/list-extended-response
Open

LIST-EXTENDED, part 1: response data item types#716
soywod wants to merge 1 commit into
duesee:mainfrom
soywod:types/list-extended-response

Conversation

@soywod

@soywod soywod commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

The LIST-EXTENDED is a big piece, so I decided to split into independent PRs. Here the part 1 that contains the response data item types.

Refs: #350

@soywod
soywod force-pushed the types/list-extended-response branch from 59aa512 to 2c408ca Compare July 29, 2026 14:24
@soywod
soywod force-pushed the types/list-extended-response branch from 2c408ca to 0ca15ab Compare July 29, 2026 14:35
@soywod soywod changed the title LIST-EXTENDED: part 1: response data item types LIST-EXTENDED, part 1: response data item types Jul 29, 2026
@soywod
soywod force-pushed the types/list-extended-response branch from 0ca15ab to b4a6b63 Compare July 29, 2026 15:12
@coveralls

Copy link
Copy Markdown
Collaborator

Coverage Report for CI Build 30464725878

Coverage decreased (-0.1%) to 91.249%

Details

  • Coverage decreased (-0.1%) from the base build.
  • Patch coverage: 17 uncovered changes across 2 files (34 of 51 lines covered, 66.67%).
  • No coverage regressions found.

Uncovered Changes

File Changed Covered %
imap-types/src/extensions/list_extended.rs 48 34 70.83%
imap-types/src/arbitrary.rs 3 0 0.0%

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 11645
Covered Lines: 10626
Line Coverage: 91.25%
Coverage Strength: 913.21 hits per line

💛 - Coveralls

@soywod

soywod commented Jul 29, 2026

Copy link
Copy Markdown
Contributor Author

Coverage should improve by itself with codec-related changes (future PRs).

@duesee

duesee commented Jul 30, 2026

Copy link
Copy Markdown
Owner

Looks good to me!

I would still need more time to read the RFC and validate all the details to vouch for it. But this is unfortunately not possible for me time-wise currently.

What do you think about this approach? We feature-gate the extension (which is our "still experimental marker") and then we can be generally more relaxed about the code, interface, structure, .... I would then basically do my best to guide you but otherwise just trust that you got the details right. If you notice (in production) that something still needs to change, we can just do the change w/o worrying about semver too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants