add HTML anchor

glessard · glessard · commit 94f00024bbca · 2024-11-20T09:30:36.000-05:00
diff --git a/proposals/AAAA-stdlib-span-properties.md b/proposals/AAAA-stdlib-span-properties.md
@@ -207,7 +207,7 @@ extension Foundation.Data {
 }
 ```
 
-#### Performance of the `storage` and `bytes` properties
+#### <a name="performance"></a>Performance
 
 The `storage` and `bytes` properties should be performant and return their `Span` or `RawSpan` with very little work, in O(1) time. This is the case for all native standard library types. There is a performance wrinkle for bridged `Array` and `String` instances on Darwin-based platforms, where they can be bridged to Objective-C types that do not guarantee contiguous storage. In such cases the implementation will eagerly copy the underlying data to the native Swift form, and return a `Span` or `RawSpan` pointing to that copy.
 

Original file line number	Diff line number	Diff line change
`@@ -207,7 +207,7 @@ extension Foundation.Data {`
`207`	`207`	`}`
`208`	`208`	```
`209`	`209`
`210`		-#### Performance of the `storage` and `bytes` properties
	`210`	`+#### <a name="performance"></a>Performance`
`211`	`211`
`212`	`212`	The `storage` and `bytes` properties should be performant and return their `Span` or `RawSpan` with very little work, in O(1) time. This is the case for all native standard library types. There is a performance wrinkle for bridged `Array` and `String` instances on Darwin-based platforms, where they can be bridged to Objective-C types that do not guarantee contiguous storage. In such cases the implementation will eagerly copy the underlying data to the native Swift form, and return a `Span` or `RawSpan` pointing to that copy.
`213`	`213`