After some discussion in other issues (#21 (comment)) and on Discord, I think this is probably not great to use positional arguments. GraphQL arguments are named/keyed so, while the object syntax is awkward in JS, I think it's best to stick with it since it more semantically matches GraphQL. At some point in the future we could come back to this if we think the ergonomic value outweighs modeling GraphQL semantics accurately.

Another point in favor of this approach is the ergonomics of default values, especially when combined with descriptions.

/** @gqlField */
export async function searchItems(
  _: Query,
  {
    query,
    first = 100,
  }: {
    query: string;
    /** Must be between 100 and 10,000 */
    first?: Int;
  }
): Promise<SearchItemsConnection> {
  // ...
}

Is much more painful than:

/** @gqlField */
export async function searchItems(
  _: Query,
  query: string,
  /** Must be between 100 and 10,000 */
  first?: Int = 10
): Promise<SearchItemsConnection> {
  // ...
}

Another argument in favor of this approach came up in Discord and I figured I'd document it here:

One appealing pattern which is uniquely enabled by implementation first solutions like Grats is that you can reuse your model types as the skeleton of your GraphQL Schema.

For example, if you had a user model:

class User {
  name: string;
  greet(salutation: string): string;
}

And you wanted to expose it in the graph:

/** @gqlType */
class User {
   /** @gqlField */
  name: string;
   /** @gqlField */
  greet(salutation: string): string  {
    return `${salutation} ${this.name}`
  };
}

Today you'd either need to add a new field for greet that accepted its args as an object, or change the signature of the existing greet field to be less ergonomic for internal use. However, if we supported positional arguments, you could expose it as written without needing to duplicate it or modify it.

As I think more about this, one of the key value Grats unlocks, is to expose existing methods as fields. I think enabling that type of developer experience might bring this feature back into the set of things we should consider doing.

I took a stab at migrating a TypeGraphQL app to Grats this evening, and found that not having support for positional args made it rather difficult. Ideally, one could just:

1. Add Grats annotations to existing code to match the TypeGraphQL decorators
2. Validate that the Grats schema and TypeGraphQL schema match
3. Delete all the TypeGraphQL directives

Right now that's not possible due to Grats requiring object shaped args.