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

Add proposal to clarify nullable #2050

Merged
merged 15 commits into from
Nov 12, 2019

Conversation

tedepstein
Copy link
Contributor

@darrelmiller , @webron , @handrews , as discussed on today's TSC call...

This adds a formal proposal to clarify the semantics of the nullable keyword, providing the necessary background and links to related resources. This should clear the way for PRs #2046 and (with modifications for 3.1) #1977.

Updating master from upstream repo
Catching up with changes in the upstream repo.
…. This adds a formal proposal to clarify the semantics of nullable, providing the necessary background and links to related resources.
Somehow in our collaborative editing, we neglected to state that `nullable` adds `"null"` to the set of allowed types. We just said that it "expands" the `type` value, but didn't state the obvious (to us) manner of said expansion. Correcting that oversight in this commit.
@philsturgeon
Copy link
Contributor

I thought proposals were just for new functionality and used x- keywords, not for any text clarification in a patch version? Was this discussed on the call I missed? Is this maybe a bit heavy handed?

@tedepstein
Copy link
Contributor Author

@philsturgeon ,

I thought proposals were just for new functionality and used x- keywords, not for any text clarification in a patch version?

Generally used for a new feature or improvement that is too big or complicated to discuss in a single issue, spans multiple issues, or benefits from having a formal spec that can evolve over time as it's being discussed. A proposal does not necessarily use x- extension properties...

Are you maybe confusing proposals with draft features? I think they are separate but related things. A draft feature will often have an associated proposal, but not all proposals generate draft features.

To put it another way: Proposals are a format for documenting and evolving a specification. Draft features are a lifecycle process to encourage trial implementations and feedback.

Was this discussed on the call I missed? Is this maybe a bit heavy handed?

It was discussed, yes. @darrelmiller suggested it, in this case, so we have a written record of the problem we intend to solve, how we arrived at the solution, how it works, etc. Something separate from the spec that we can refer to and link to if questions come up.

In other projects, this might be called a technical note, an addendum, appendix, or something else. In this project, the proposal format seems to fit the bill.

I believe the intent is for the TSC to review and expedite approval, having already discussed it on the call. So using the proposal format should not be a barrier to getting the 3.0.3 patch release and the 3.1 feature release done.

@handrews handrews mentioned this pull request Nov 4, 2019
@handrews
Copy link
Member

handrews commented Nov 4, 2019

@philsturgeon The rationale here is that there are potentially tons of little subtleties with this, and cluttering the spec with them would be bad. It would emphasize misinterpretations (of great interest to existing users) over clarity (much better for new readers). Having a formal accounting of all of the details but not putting them all in the spec itself splits the difference nicely.

@philsturgeon
Copy link
Contributor

Cool, if we're doing things properly then all my thumbs! 👍 👍

@tedepstein
Copy link
Contributor Author

@darrelmiller or @webron, could you please merge this PR? It is just adding the proposal, as we discussed, and making a minor correction to the proposal template.

Merging the PR doesn't mean the proposal is accepted by the TSC, it just acknowledges that the proposal has been submitted. Having the proposal available in the master branch makes it easier to discuss with the community.

@philsturgeon
Copy link
Contributor

philsturgeon commented Nov 5, 2019

Wait we have to merge the proposal, then discuss it again in the future, then maybe merge the change which we've already got, which... will take how long? Are we gonna have to do this for #1977 too? I've already got a few grey hairs showing up in this beard and at this rate I'm concerned I won't see #1977 happen before I look like this guy. 🎅🏻 At least Christmas is coming up? 😂

@tedepstein
Copy link
Contributor Author

tedepstein commented Nov 5, 2019

We have already discussed it, so I don't think TSC approval is going to be held up.

I only said the bit about merging not implying acceptance to soothe any apprehension that @webron or @darrelmiller might have, so they'll go ahead and click that 'merge' button. (SSShhhhh!!! Don't tell them!)

@darrelmiller darrelmiller merged commit 1d4e51f into OAI:master Nov 12, 2019
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 this pull request may close these issues.

4 participants