Skip to content

AttributedString Index Validity APIs #1177

New issue

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

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

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 28, 2025

Conversation

jmschonfeld
Copy link
Contributor

This PR implements the index validity checking APIs as proposed in SF-0015 by adding a new version number tracked within each AttributedString and AttributedString.Index. As neither type is frozen, we have the flexibility in the future to optimize this (for example, by taking advantage of the version number stored within the already-nested BigString.Index if the swift-collections package provided access to it) if we deem necessary.

@jmschonfeld
Copy link
Contributor Author

@swift-ci please test

@jmschonfeld jmschonfeld force-pushed the attrstr/index-validation branch from 98cabe4 to 877b55f Compare February 19, 2025 00:35
@jmschonfeld
Copy link
Contributor Author

@swift-ci please test

@jmschonfeld
Copy link
Contributor Author

@swift-ci please test macOS platform

self.lowerBound >= text.startIndex &&
self.lowerBound <= text.endIndex &&
self.upperBound._version == text.__guts.version &&
self.upperBound >= text.startIndex &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Checking my logic here... Do you need both self.lowerBound >= text.startIndex and self.upperBound >= text.startIndex?

I thought a Range has the precondition of lowerBound<=upperBound, so doesn't self.lowerBound >= text.startIndex guarantee self.upperBound >= text.startIndex?

Same question goes with self.lowerBound <= text.endIndex && self.upperBound <= text.endIndex

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right Range has that precondition so both checks aren't required. I can update this to simplify the expressions down a bit

//
//===----------------------------------------------------------------------===//

#if canImport(Synchronization)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other places we have #if canImport(Synchronization) && FOUNDATION_FRAMEWORK. Is that wrong?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously we needed the && FOUNDATION_FRAMEWORK because non-FOUNDATION_FRAMEWORK builds ran on a very old version of macOS in CI where we back deployed back to a version that didn't have Synchronization (even though the canImport(Synchronization) check passes because it was in the SDK). Now that we've bumped the deployment target of the package, we can safely use the Synchronization module on the macOS version CI is back deployed to, so no need to guard with FOUNDATION_FRAMEWORK (but there are still some edge case situations where the module doesn't exist at all that we need to guard for with the canImport check)

private static let _nextVersion = Atomic<Version>(0)

static func createNewVersion() -> Version {
_nextVersion.wrappingAdd(1, ordering: .relaxed).oldValue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I'd probably put the #if canImport(Synchronization) inside this function since that's implementation detail

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure I can do that if you prefer - I still would need a separate canImport check around the private static let variables since their types are different, but if you want I can split it into two canImport checks, one for around the variable and one within the body of the function

@jmschonfeld
Copy link
Contributor Author

@swift-ci please test

@jmschonfeld
Copy link
Contributor Author

@swift-ci please test

@jmschonfeld jmschonfeld merged commit de6af53 into swiftlang:main Feb 28, 2025
3 checks passed
@jmschonfeld jmschonfeld deleted the attrstr/index-validation branch February 28, 2025 20:18
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.

2 participants