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

[swift2objc] Extend Builtin Declarations (mainly builtin protocols) #1827

Open
nikeokoronkwo opened this issue Dec 18, 2024 · 4 comments
Open

Comments

@nikeokoronkwo
Copy link
Contributor

nikeokoronkwo commented Dec 18, 2024

This issue is to add more builtin declarations to the ones already existing in the swift2objc tool:
A few of the main categories of declarations to add are here

Inbuilt Protocols

Swift has a set of inbuilt Core Protocols that can be used by classes, structs, other protocols and generics in type constraints. A few common ones are: Hashable, Numeric, Collection, Error etc.

When making use of such protocols in classes, the protocol implementations are not automatically added to the symbol graph (although they are present, like other inbuilt types like String), and so would need to be added as a builtin declaration.

More Inbuilt Types

A few more types may need to be added, like Dictionary, Array, Set, Slice, etc. Some of these types also make use of generics


Hopefully by the end of this issue a good amount of the builtin declarations will be present.
A full list of the builtin types in the swift standard library can be found here: https://developer.apple.com/documentation/swift/swift-standard-library

@nikeokoronkwo
Copy link
Contributor Author

There are a lot of items under the Swift Standard Library, so we might not import all of them. However, it would be helpful to layout the groundwork for such so that if we encounter any libraries containing types not included here, they can easily be added.

This would mean dropping the current enum approach for a more inclusive approach that can include other types like protocols, enums and more. By the way, most swift types are actually structs under the hood, and some even have nested declarations (e.g Swift.UTF16View), which need to be considered, which is why the enum approach would need to be dropped.

@liamappelbe
Copy link
Contributor

This would mean dropping the current enum approach for a more inclusive approach that can include other types like protocols, enums and more.

Yeah, I was working on another refactor and found that I needed to change BuiltInDeclaration to a class. I'll try and get that refactor into a PR today.

@liamappelbe
Copy link
Contributor

When making use of such protocols in classes, the protocol implementations are not automatically added to the symbol graph (although they are present, like other inbuilt types like String), and so would need to be added as a builtin declaration.

What exactly is going on with these protocols? Where are they defined? My hunch is they're not actually built-in, but are defined in Foundation. If that's the case, then instead of adding these protocols as built-ins, we'll be parsing them automatically once #1774 is implemented.

@nikeokoronkwo
Copy link
Contributor Author

When making use of such protocols in classes, the protocol implementations are not automatically added to the symbol graph (although they are present, like other inbuilt types like String), and so would need to be added as a builtin declaration.

What exactly is going on with these protocols? Where are they defined? My hunch is they're not actually built-in, but are defined in Foundation. If that's the case, then instead of adding these protocols as built-ins, we'll be parsing them automatically once #1774 is implemented.

The protocols are actually built in as a part of the Swift Standard Library, and are actually separate from Foundation. Some protocols that are in the standard library are: Collection, Hashable, Numeric, Equatable and more.

Foundation has its own set of protocols, structs and other declarations. Some protocols in the Foundation library are: DataProtocol, NSFastEnumeration

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

2 participants