Add proposal to clarify nullable

[tedepstein]

@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.

[philsturgeon]

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]

@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]

@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]

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

[tedepstein]

@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]

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]

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!)