Skip to content

Merge IncrementalEdit and SourceEdit #2532

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
ahoppen opened this issue Mar 6, 2024 · 1 comment · Fixed by #2604
Closed

Merge IncrementalEdit and SourceEdit #2532

ahoppen opened this issue Mar 6, 2024 · 1 comment · Fixed by #2604
Assignees
Labels
refactoring An internal refactoring of the codebase

Comments

@ahoppen
Copy link
Member

ahoppen commented Mar 6, 2024

After #2527, IncrementalEdit and SourceEdit are more or less equivalent types. Both store a replacement range and a replacement. The only meaningful difference is that SourceEdit has String as a replacement and IncrementalEdit has an array of bytes as a replacement and can thus also represent invalid UTF-8. We should merge them, ideally into a type that is byte-based (because it’s more versatile) but that offers String-based accessors.

The best outcome would be if SourceEdit could be the type that’s used to represent the edits, IncrementalEdit becomes a deprecated typealias to SourceEdit and SourceEdit gains (possibly deprecated) members for all the members that IncrementalEdit had, for API compatibility.

@ahoppen ahoppen added the refactoring An internal refactoring of the codebase label Mar 6, 2024
@ahoppen
Copy link
Member Author

ahoppen commented Mar 6, 2024

Tracked in Apple’s issue tracker as rdar://124118127

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
refactoring An internal refactoring of the codebase
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants