i filed a bug about this before i got access to kotlin slack, but is there a way to use `@GraphQLID`...

# graphql-kotlin

[Lenny]

i filed a bug about this before i got access to kotlin slack, but is there a way to use @GraphQLID to create an argument for a list of ids, like foo(ids: [ID!]!) ?

[Shane Myrick]

Hey Lenny, I replied to your comment in github

https://github.com/ExpediaGroup/graphql-kotlin/issues/698#issuecomment-625971571

[Lenny]

cool, thanks for the response! we’re finally able to use kotlin on the server here and i’m having a lot of fun rewriting our code to use graphql-kotlin 😄

[Shane Myrick]

@Lenny As an user would you rather prefer:

• Support for both @GraphQLID and ID
• Or drop support for the annotation and only use the ID wrapper class?

[Lenny]

seems like having only one API would be better for documentation and support purposes

[Lenny]

but introducing the wrapper type and having both until a major version bump makes sense to me

[Shane Myrick]

Yea, that is what we prefer as well. Since we already had a breaking change coming up (unintentional non-null with the errors field) we think we are just going to roll forward with a forced update

[Lenny]

sounds good to me! … though i’m hardly your only customer and i’m just barely one at that 😁

[Robert]

what would be as awsome:
Support on inline classes (as typealias can't have annotations)

[Shane Myrick]

I briefly tried getting my PR to work with inline classes but was running into issues with Jackson.

If we migrate to the wrapper class then making it inline would be a minor change only we can add later as well

https://github.com/FasterXML/jackson-module-kotlin/issues/199

[Shane Myrick]

Plus they are still experimental and require a compiler flag. For now I think we may hold off until they are released as we can more easily do a compare of the improvements if we first migrate to the wrapper class