(In reply to Masatoshi Kimura [:emk] from comment #1) > We have several ways to assert non-nullness; OwningNonNull, mozilla::NotNull, MOZ_NONNULL, MOZ_NONNULL_RETURN... (Don't ask me why there are so many ways.) Although, it's possible of a nullptr-referece, using reference of C++ is reasonable because: 1. Using `OwningNonNull` as an argument is not a standard manner because of the refcount cost in the hot paths 2. `NotNull` was designed for multiple compilers and avoiding some complicated special cases. So we don't have any reasons to use it in editor because using it may increase the binary size 3. I don't believe 100% of static analysis due to edge cases, so I don't believe `MOZ_NONNULL` etc in unrealistic scenarios Currently, we use clang in any platforms and crashes near null are not treated as security issues. So just using C++'s future must be fine in the editor module.
Bug 1623210 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Masatoshi Kimura [:emk] from comment #1) > We have several ways to assert non-nullness; OwningNonNull, mozilla::NotNull, MOZ_NONNULL, MOZ_NONNULL_RETURN... (Don't ask me why there are so many ways.) Although, it's possible of a nullptr-referece, using reference of C++ is reasonable because: 1. Using `OwningNonNull` as an argument is not a standard manner because of the refcount cost in the hot paths 2. `NotNull` was designed for multiple compilers and avoiding some complicated special cases. So we don't have any reasons to use it in editor because using it may increase the binary size 3. I don't believe 100% of static analysis due to edge cases, so I don't believe `MOZ_NONNULL` etc in unrealistic scenarios Currently, we use clang in any platforms and crashes near null are not treated as security issues. So just using C++'s feature must be fine in the editor module.
(In reply to Masatoshi Kimura [:emk] from comment #1) > We have several ways to assert non-nullness; OwningNonNull, mozilla::NotNull, MOZ_NONNULL, MOZ_NONNULL_RETURN... (Don't ask me why there are so many ways.) Although, it's possible of a nullptr-referece, using reference of C++ is reasonable because: 1. Using `OwningNonNull` as an argument is not a standard manner because of the refcount cost in the hot paths 2. `NotNull` was designed for multiple compilers and avoiding some complicated special cases. So we don't have any reasons to use it in editor because using it may increase the binary size 3. I don't believe 100% of static analysis due to edge cases, so I don't believe `MOZ_NONNULL` etc in unrealistic scenarios Currently, we use clang in any platforms and crashes near null are not treated as non-security issues. So just using C++'s feature must be fine in the editor module.
(In reply to Masatoshi Kimura [:emk] from comment #1) > We have several ways to assert non-nullness; OwningNonNull, mozilla::NotNull, MOZ_NONNULL, MOZ_NONNULL_RETURN... (Don't ask me why there are so many ways.) Although, it's possible of a nullptr-referece, using reference of C++ is reasonable because: 1. Using `OwningNonNull` as an argument is not a standard manner because of the refcount cost in the hot paths 2. `NotNull` was designed for multiple compilers and avoiding some complicated special cases. So we don't have any reasons to use it in editor because using it may increase the binary size 3. I don't believe 100% of static analysis due to edge cases, so I don't believe `MOZ_NONNULL` etc in unrealistic scenarios which should be banned by the review process Currently, we use clang in any platforms and crashes near null are not treated as non-security issues. So just using C++'s feature must be fine in the editor module.