On 25/08/2016 06:14, Nicholas Nethercote wrote:
On Wed, Aug 24, 2016 at 9:38 PM, Gijs Kruitbosch
<gijskruitbo...@gmail.com> wrote:
I'm mostly in frontend Firefox land so excuse the potentially dumb question
and probably incorrect terminology... My impression was that we already have
things like NonNull, and if we are now forcing nsresult codes to be actually
used, presumably we could just as well indicate whether particular IDL
properties could/couldn't be null, and accept a check on that rather than
the rv if the idiom is very common?
I'm not sure if this addresses your comment directly, but: IDL methods
have to return nsresult to satisfy interface requirements. Because
xptcall, which is the code that handles these calls from C++ land and
JS land, expects an nsresult return value. Changing this would be
difficult.
Sorry, I'm not being very clear, I'm afraid. I'm not asking to ditch
nsresult.
I'm wondering if we can make a "smarter" annotation than [must_use] that
requires *either* a nullcheck on the outparam or an nsresult check
(rather than requiring the latter and not being satisfied with a
nullcheck on the outparam). I don't know if that's feasible with today's
compilers and/or static checking, but it seemed worth asking.
If we could do something like that, in theory it might also be possible
to use it to annotate some of the wonky behaviour bz and you referenced
where nullchecking the outparam isn't enough (ie [must_use] vs. whatever
we call the other thing would indicate whether a non-null outparam was
enough to guarantee that the nsresult was NS_OK and everybody was happy.).
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
