Comments (3)
That sounds sensible, and I like it a lot for an additional reason:
Removing MODULE
would at least marginally decrease the chances that users would encounter the crash discussed in #302. In fact, if we imagine a world in which users use @NullMarked
only at the class, package, and module levels, while perhaps using @NullUnmarked
on individual methods, then removing MODULE
would eliminate #302. In practice, I'm sure it wouldn't totally eliminate it. But it might help a lot.
The main counterargument I can see is that an enterprising organization might try to "flip the default" for now code so that all code is considered null-marked unless otherwise annotated :) Then they might theoretically want to unmark their already existing modules. But I'm inclined not to worry about that, thanks to some combination of:
- For that to work, every tool that the organization uses would need to support "null-marked by default."
- Some people don't make use of modules.
- It doesn't seem that hard to put in place enforcement that all new modules are
@NullMarked
. - We might even look askance at the idea that code without
@NullMarked
should be treated as null-marked in general.
from jspecify.
This is my askance look.
from jspecify.
#351 did this and updated docs accordingly.
from jspecify.
Related Issues (20)
- How to release artifacts that smooth the package move HOT 16
- documentation contrasting our semantics against the existing ones of popular tools HOT 1
- Pepper documents like the Nullness Design FAQ with issue links
- Coordinate with tool/language owners to add our annotations to their configured lists HOT 1
- Revise spec to account for all working-decisions HOT 1
- Check docusaurus build on pull requests HOT 7
- Whether an exception parameter is nullness-applicable and why HOT 14
- Delete old annotations after -alpha2
- Move unversioned docs incl web site somewhere else
- Replace @NullnessUnspecified in samples with use of @NullUnmarked
- Provide OSGI support HOT 2
- Put appropriate "(Why?)" links in the user guide as we did for the javadoc HOT 3
- Annotation Processors Ignore TYPE_USE annotations on compiled classes HOT 8
- Run reference checker tests on each PR HOT 7
- How to handle nullness with generic parameters? (specific example) HOT 5
- Support for an "always null value" HOT 3
- Is it safe to have jspecify be an optional dependency? HOT 13
- Confirming understanding of null marked generics HOT 3
- Javadoc link broken HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jspecify.