Skip to content
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

[SR-11926] FileHandle's new APIs should be more open on Linux. #3369

Closed
YOCKOW opened this issue Dec 8, 2019 · 7 comments
Closed

[SR-11926] FileHandle's new APIs should be more open on Linux. #3369

YOCKOW opened this issue Dec 8, 2019 · 7 comments
Assignees

Comments

@YOCKOW
Copy link
Collaborator

YOCKOW commented Dec 8, 2019

Previous ID SR-11926
Radar rdar://problem/57824024
Original Reporter @YOCKOW
Type Bug
Status Resolved
Resolution Won't Do
Environment

Swift 5.1.2

  • macOS 10.15.1

  • Ubuntu 18.04

Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug
Assignee @millenomi
Priority Medium

md5: 31f5454e066ba5b5796a2f74a425e0c6

Issue Description:

From Swift 5.0, new APIs of FileHandle are introduced.
Some of them are common between DarwinFoundation and SwiftFoundation such as below:

  • func close() throws

  • func seek(toOffset: UInt64) throws

  • func synchronize() throws

  • func truncate(atOffset: UInt64) throws

While they are defined as open in DarwinFoundation (as you know they are imported from objc), they are public in SwiftFoundation.
They should be defined as open also in SwiftFoundation to ensure compatibility (for example, making subclasses of FileHandle in other modules).

@beccadax
Copy link
Contributor

@swift-ci create

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Dec 12, 2019

#2585

@millenomi
Copy link
Contributor

Due to implementation details on Darwin, it is not possible to correctly subclass FileHandle on that platform. (There is no designated initializer that will not throw an exception.)

SCF just codifies this behavior explicitly.

@millenomi
Copy link
Contributor

(To be clear: in Swift. You can correctly subclass FileHandle on Darwin, because you can avoid invoking a superclass's initializer there.)

@millenomi
Copy link
Contributor

(… in ObjC)

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Jan 16, 2020

@millenomi

Thank you for the response.
I understand what you say, but please let me tell you why I filed this.

There are some cases where subclasses of FileHandle are useful. (...cough, for example, one of my projects).
On Darwin, as you said, some workarounds are required, in other words, we can make subclasses of FileHandle both on Darwin and non-Darwin even in Swift with the workarounds.
The subclasses made with such workarounds (breaking the class cluster) may not be "correct", however, there is certainly a use case of them.


If Apple does not allow making subclasses of FileHandle in Swift, there are somethings I am concerned about:

  • Why is FileHandle itself still open in SCF?

    • I mean, why only new APIs are public while deprecated APIs, other methods and computed properties were/are open?
  • I wish some appropriate protocol is introduced like FileHandleProtocol discussed in Forum's thread.

@YOCKOW
Copy link
Collaborator Author

YOCKOW commented Jan 20, 2020

List: APIs of FileHandle

____________________________________ ObjC (macOS<10.15) ObjC (macOS>=10.15) Swift (macOS<10.15) Swift (macOS>=10.15) Swift<5.0 w/SwiftFoundation Swift>=5.0 w/SwiftFoundation
Legacy methods (e.g. closeFile()) Overridable Overridable(deprecated) open open(deprecated) open open(deprecated)
New methods (e.g. close() throws) Overridable Overridable n/a open n/a public
Other methods Overridable Overridable open open open open
Making subclasses Available Available Available Available Available Available
Making useful subclasses Available Available Available with workarounds Available with workarounds Available Unavailable

SCF seems not to codify the behavior on Darwin...

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants