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

Model type variable bounds #73

Closed
tadfisher opened this issue Nov 28, 2023 · 2 comments · Fixed by #75
Closed

Model type variable bounds #73

tadfisher opened this issue Nov 28, 2023 · 2 comments · Fixed by #75

Comments

@tadfisher
Copy link
Collaborator

tadfisher commented Nov 28, 2023

For Swift, generics can't be decoded without the type variable implementing Decodable. For example:

import Data.Tree

mobileGen ''Tree

Currently this produces:

/// Non-empty, possibly infinite, multi-way trees; also known as *rose trees*.
struct Tree<A> {
    /// label value
    var rootLabel: A
    /// zero or more child trees
    var subForest: [Tree<A>]
}

At compile time, the Swift program can pass a type to use when decoding subForest like so:

tree.map(Tree<String>.self)

The problem, though, is that A needs to be annotated with the Decodable protocol for this to work, like struct Tree<A : Decodable>. To do this, we can pass structTyVars = ["A : Decodable"], but this won't work in Kotlin.

If tyvars were modeled with type names and bounds, then we could implement this separately for Swift and Kotlin.

Related: #13

@kylebshr
Copy link
Contributor

I think we want the same conformance as our other types get (Equatable, Hashable, Codable) - though, I'm not sure what decides that. But this would look like this:

struct GenericType<A: Equatable & Hashable & Codable>: Equatable, Hashable, Codable {
    var genericProperty: A
}

@chessai
Copy link
Collaborator

chessai commented Jan 29, 2024

@kylebshr Look at the rose tree tyvar unfolding code. That might be helpful here. Actually, nvm, we can probably just do some simple constraint synthesis. If we add Codable et al to a type, we need to demand that its type variables all have that, too. So I don't think this change would actually be that complicated - just a pretty printer change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants