David P. Baker

Decision: Lambda parameters that are `var` or untyped have their nullness inferred. `@Nullable` and `@NonNull` apply to those with explicit types just like method parameters.

**Current decision**: Disregarding implied annotations, if two contradictory annotations annotate the same type usage (`@Nullable @NonNull Foo`), then both are ignored as irrelevant. **Argument for changing**: No strong case. **Timing**:...

> To be clear, we mean when analyzing _dependents_ of the errant API the annotations are classified as irrelevant/unrecognized/meaningless*. When that signature itself is being analyzed it would certainly produce...

**Decision**: Disregarding implied annotations, if two contradictory annotations annotate the same type usage (`@Nullable @NonNull Foo`), then both are unrecognized.

We're working on replacing the samples with conformance tests, but we've decided this is not blocking for the 1.0 release.

I remain convinced that the simplest specification is best. * Unprojected type variable usage in null-unmarked scope: unspecified. `@NullUnmarked T foo();` returns `T*`. * Projected type variable usage in null-unmarked...

**Current decision**: In the case of ``` @NullMarked interface Foo { T returnT(); } ``` when tools encounter `@NullUnmarked Foo foo();`, they should treat it as a "possible mismatch", because...

**Current decision**: We will not include this feature in 1.0. **Proposal for 1.0: Finalize the current decision.** If you agree, please add a thumbs-up emoji (👍) to this comment. If...

**Current decision**: This feature is not required for JSpecify 1.0. **Proposal for 1.0: Finalize the current decision.** If you agree, please add a thumbs-up emoji (👍) to this comment. If...

**Current decision**: JSpecify 1.0 will not explicitly address this problem. **Proposal for 1.0: Finalize the current decision.** If you agree, please add a thumbs-up emoji (👍) to this comment. If...