-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[stdlib] Add StaticString.UnicodeScalarView #277
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
Conversation
|
Doesn't this require a swift-evolution proposal since it changes the stdlib API? |
|
It does require a swift-evolution proposal. The proposal should include a condensed dump of the proposed API with documentation. Please don't spend more time improving the code before the proposal is approved, but a general comment about tests is that every public API and every protocol conformance should be tested. |
test/1_stdlib/StaticString.swift
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests should be added before runAllTests(), or they won't be run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops.
|
Does every single stdlib API require a full proposal that has gone through the entire submission and review process? Seems like that could get very tedious. Or can relatively simple changes get by with just discussing it on the swift-evolution mailing list? |
Yes, every API change that affects the user-visible API should go through swift-evolution. We have been using this process internally, and it worked well.
Relatively simple changes don't require long discussions and long proposals :) A simple email to swift-evolution and a small proposal that doesn't have much more than a simple statement of motivation and the API diff would be sufficient. Of course, assuming it is a simple change. |
Add a new type `StaticString.UnicodeScalarView`, accessible via a property `.unicodeScalars` on `StaticString`. Also add initializers for `StaticString` that take a `UnicodeScalarView` or a `Slice<UnicodeScalarView>`. The motivating reason for this is to make it possible to slice a `StaticString` down to a substring that's still typed as `StaticString`. Fixes rdar://problem/23382521
13ce8c2 to
9500d87
Compare
|
PR updated to actually run the tests. |
|
The related proposal has now been merged as SE-0010 and is Awaiting Review. |
|
Since the swift-evolution request was rejected with rational, can I close this pull request? |
|
I guess so. It's a shame, since there really should be some way of producing a slice of a |
|
Thanks! |
Remove dependency on sys_membarrier on linux
Remove dependency on sys_membarrier on linux Signed-off-by: Daniel A. Steffen <[email protected]>
Update ProcedureKit to build against Swift 4.2
Add a new type
StaticString.UnicodeScalarView, accessible via aproperty
.unicodeScalarsonStaticString. Also add initializers forStaticStringthat take aUnicodeScalarViewor aSlice<UnicodeScalarView>.The motivating reason for this is to make it possible to slice a
StaticStringdown to a substring that's still typed asStaticString,without losing the guarantee of being well-formed UTF8.
Fixes rdar://problem/23382521