-
Notifications
You must be signed in to change notification settings - Fork 109
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
Enable strict null checking #26
Conversation
Note: after merging the latest changes from master, this generates one more interesting error, that shows a possible null return that I think is worth review/discussion.
I don't understand from the comments if null is an expected return type for this function. |
I'm leaving the interesting errors in place for discussion. They do not block code generation or test success. |
Hmm, perhaps because I merged out-of-order, but right now this generates two implicit any errors:
My last checkin fixed these. |
@@ -125,7 +125,10 @@ class IterableAdapter<T> implements Iterable<T>, IterableIterator<T> { | |||
[Symbol.iterator]() { this._iterator = this.collection.iterator(); return this;} | |||
|
|||
next(): IteratorResult<T> { | |||
if (!this._iterator.hasNext()) return { done: true, value: undefined }; | |||
if (!this._iterator.hasNext()) { | |||
// A bit of a hack needed here, tracking under https://github.com/Microsoft/TypeScript/issues/11375 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you said you'd handle this. P.S. Perhaps we should eliminate the |
Note this version generates some errors, all of which seem valid to me. If we adopt this, it seems like it could replace the @NotNull decorator.
This change is based on work originally completed by @BurtHarris in #26.
This work is based on changes by @BurtHarris in #26.
Closes #14. I think you'll like this Sam.
Note this version generates some errors (of the form
error TS2531: Object is possibly 'null'
) all of which seem valid to me. If we adopt this, it seems like it could replace the@NotNull
decorator. (All errors are non-fatal, the tests still run.)Seems like if we want to use this, the sooner the better.