[stdlib] Mark public classes as 'open'.

[jrose-apple]

Depends on #3875 (or the full implementation of open). PR for review by the stdlib team.

---

Before merging this pull request to apple/swift repository:

• Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform	Comment
All supported platforms	@swift-ci Please smoke test
All supported platforms	@swift-ci Please smoke test and merge
OS X platform	@swift-ci Please smoke test OS X platform
Linux platform	@swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

1. Builds the compiler incrementally.
2. Builds the standard library only for macOS. Simulator standard libraries and
   device standard libraries are not built.
3. lldb is not built.
4. The test and validation-test targets are run only for macOS. The optimized
   version of these tests are not run.

A smoke test on Linux does the following:

1. Builds the compiler incrementally.
2. Builds the standard library incrementally.
3. lldb is built incrementally.
4. The swift test and validation-test targets are run. The optimized version of these
   tests are not run.
5. lldb is tested.

Validation Testing

Platform	Comment
All supported platforms	@swift-ci Please test
All supported platforms	@swift-ci Please test and merge
OS X platform	@swift-ci Please test OS X platform
OS X platform	@swift-ci Please benchmark
Linux platform	@swift-ci Please test Linux platform

Lint Testing

Language	Comment
Python	@swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

[jrose-apple]

@gribozavr, do these need to be open, or just public?

[gribozavr]

They are subclassed in the Foundation module. I would prefer to move them from the core library into the Foundation overlay, but that is a separate project.

Could you add a comment // FIXME(ABI): move into the Foundation overlay and remove 'open'. to each one?

[jrose-apple]

Will do, thanks for the review.

[jrose-apple]

@mwwa, is DispatchWorkItem intended to be subclassed or no?

[mwwa]

Pretty sure we're aiming for no, though I suspect it never had final added to it (mostly because all the other Dispatch classes can't have final added and it got missed).

@das ?

[jrose-apple]

Yeah, I asked because I did a grep for public classes and filtered out the final ones.

[mwwa]

As an aside, if we could make the other dispatch classes explicitly final then they should be too. I don't think we can do that when the class is defined in ObjC, right? (Even though you generally can't subclass them because of objc_runtime_visible.

[jrose-apple]

Yeah, the reason the imported types aren't final is because the compiler will optimize based on that, and it can't prove there aren't any non-public subclasses. I don't think that should rule out marking this one final, though. (Unless you think there might be an internal class hierarchy in the future. That was the whole point of the open proposal.)

[das]

@mwwa re DispatchWorkItem, unlike most other Dispatch classes I could see that one being useful to subclass, but I don't think we have the technical ability to do so at this point ?

All other Dispatch classes are not currently intended or able to be subclassed.

[jrose-apple]

Okay, it sounds like it's best to leave the possibility open, i.e. leave it as is.

[jrose-apple]

@swift-ci Please smoke test

[jrose-apple]

@swift-ci Please smoke test

[jrose-apple]

@swift-ci Please smoke test Linux platform