Skip to content
This repository has been archived by the owner on Apr 15, 2024. It is now read-only.

Refactor the type system #64

Open
vinivendra opened this issue Jun 19, 2020 · 0 comments
Open

Refactor the type system #64

vinivendra opened this issue Jun 19, 2020 · 0 comments
Labels
no solution yet It is not yet clear how to solve this issue

Comments

@vinivendra
Copy link
Owner

There are several complicated algorithms (many of which haven't been implemented yet, like #63) that would be easier to do if we had a decent type system.

Instead of using strings for all types, we could have a more complicated structure. Something like

indirect enum SwiftType {
    case simpleType(String) // `Int`
    case functionType(parameter: [String], return: String) // `(Int) -> Int
    case tupleType([String]) // (Int, Int)
    case dotType(left: String, right: String) // String.Index
    case genericType(type: String, genericParameters: [String], constraints: [TypeConstraint]) // Array<Element> where Element :Equatable
}
@vinivendra vinivendra added bug Something isn't working no solution yet It is not yet clear how to solve this issue and removed bug Something isn't working labels Jun 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
no solution yet It is not yet clear how to solve this issue
Projects
None yet
Development

No branches or pull requests

1 participant