-
Notifications
You must be signed in to change notification settings - Fork 46
Translate constructor of structs #70
Comments
Hi @sgade, thanks for filing this issue (and the others). We still need to figure out a more comprehensive solution for initializers everywhere, but perhaps we can find (or implement) a solution for your use case in the meantime. Would you be OK with using something like this in Swift? public struct FoodSpecial {
public let id: String = "a"
public let title: String
public let subtitle: String
public let price: Double
}
// OK
let food = FoodSpecial(title: "", subtitle: "", price: 0)
// Not allowed by Swift:
// let otherFood = FoodSpecial(id: "2", title: "", subtitle: "", print: 0) This currently gets translated to data class FoodSpecial(
val id: String = "a",
val title: String,
val subtitle: String,
val price: Double
)
fun main(args: Array<String>) {
val food: FoodSpecial = FoodSpecial(title = "", subtitle = "", price = 0.0)
} which works in Kotlin. If this doesn't work for you, let me know why and we'll figure something out. |
Thanks for your quick reply! I like the idea of using warnings to inform the user that a certain feature is not (yet) support. Do you think it would make sense do add a warning for this case? It might refer the user to using the possible fix you suggested here. |
Yeah, I don't think we currently support any initializers in structs, so it would make sense to raise warnings when we find them. |
I just noticed again why I was using explicit initialisers: The structs I am translating are located in a Swift package and therefore need an explicit Now I could create something business-y like Factories. I guess in my particular case there is not disadvantage in using classes instead. |
Ok! I'm gonna implement the warnings for now, but I'll leave this issue open until the initializers are properly fixed. You could probably ignore your Swift initializer with |
Is your feature request related to a problem? Please describe.
Using a
struct
to manage data, in Swift you can add an initialiser for storing the properties:this is translated by Gryphon to a
data class
with aconstructor
:Describe the solution you'd like
According to my Kotlin knowledge, the best way to implement the behavior would be to use default values. See this example:
Describe alternatives you've considered
As data classes cannot have
constructor
s, this seems to be the best way to approach this.Additional context
none
The text was updated successfully, but these errors were encountered: