Lee Byron

At this point I think we're good to RFC 3 approve - I'd like to wait on a final OK from @magicmark and at least a first review from @IvanGoncharov...

@andimarek Excellent questions, I agree they're very relevant. > * What is the impact of this new type on the underlying GraphQL structure? What I mean with that is: does...

I want to highlight that even if we decide to scope this down to the input case only, the exercise of detailing out how such a type would support both...

This was an intentional decision to balance between expressiveness and complexity. While the subject of your proposal is absolutely true: we cannot communicate the difference between optionality and nullability in...

This has been open for a while, but I'm marking it as straw man and needs champion to see if anyone has a compelling approach for this problem. If there's...

I love this, and to elaborate a bit and try to apply some definitions and following thoughts: This is client control to transform a Nullable to a Non-Null, but I...

> Non-Null fields to Nullable. As you describe, it adds a lot of complexity and edge cases. But I have a hard time seeing compelling uses cases that would warrant...

> To solve the nullable list items, what do folks think about this syntax? To extend the example above: > Do you see any pitfalls or drawbacks? Two major drawbacks:...

Thanks for writing this up, Oleg! I'm a bit confused as to what this is enabling that isn't already possible or what the immediate goal of using namespaces would be....

@IvanGoncharov illustrated a number of API design abuse patterns that worry me as well. I've still yet to hear a compelling argument for why namespaces are necessary. The only argument...