Skip to content

Conversation

@lilyball
Copy link
Contributor

@lilyball lilyball commented Dec 6, 2015

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,
without losing the guarantee of being well-formed UTF8.

Fixes rdar://problem/23382521

@radex
Copy link
Contributor

radex commented Dec 6, 2015

Doesn't this require a swift-evolution proposal since it changes the stdlib API?

@gribozavr gribozavr added the swift evolution pending discussion Flag → feature: A feature that has a Swift evolution proposal currently in review label Dec 6, 2015
@gribozavr
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops.

@gribozavr gribozavr changed the title Implement StaticString.UnicodeScalarView Add StaticString.UnicodeScalarView Dec 6, 2015
@lilyball
Copy link
Contributor Author

lilyball commented Dec 6, 2015

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?

@gribozavr
Copy link
Contributor

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.

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.

Or can relatively simple changes get by with just discussing it on the swift-evolution mailing list?

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
@lilyball
Copy link
Contributor Author

lilyball commented Dec 6, 2015

PR updated to actually run the tests.

@lilyball lilyball changed the title Add StaticString.UnicodeScalarView [stdlib] Add StaticString.UnicodeScalarView Dec 6, 2015
@lilyball
Copy link
Contributor Author

The related proposal has now been merged as SE-0010 and is Awaiting Review.

@gottesmm
Copy link
Contributor

Since the swift-evolution request was rejected with rational, can I close this pull request?

@lilyball
Copy link
Contributor Author

I guess so. It's a shame, since there really should be some way of producing a slice of a StaticString, but it was rejected so I guess that's that.

@lilyball lilyball closed this Feb 26, 2016
@gottesmm
Copy link
Contributor

Thanks!

slavapestov pushed a commit to slavapestov/swift that referenced this pull request Nov 27, 2018
Remove dependency on sys_membarrier on linux
slavapestov pushed a commit to slavapestov/swift that referenced this pull request Nov 27, 2018
Remove dependency on sys_membarrier on linux

Signed-off-by: Daniel A. Steffen <[email protected]>
freak4pc pushed a commit to freak4pc/swift that referenced this pull request Sep 28, 2022
Update ProcedureKit to build against Swift 4.2
@AnthonyLatsis AnthonyLatsis added swift evolution rejected Flag → feature: A feature that was rejected through the Swift evolution process and removed swift evolution pending discussion Flag → feature: A feature that has a Swift evolution proposal currently in review labels Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

swift evolution rejected Flag → feature: A feature that was rejected through the Swift evolution process

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants