The Web IDL draft allows for null parameters such: attribute readonly double foopy; If foopy can not be determined, it may return null (instead of throwing). The syntax is '?', so you'd have something like: attribute readlonly double? foopy; See http://www.w3.org/TR/WebIDL/#idl-nullable-type for details. This is a fall out from bug 615597 where we have many params that, if they can not be determined, we return null.

Fallout from bug 662678.

Also see the more up-to-date dev.w3.org version of the spec, which has expanded to allowing (requiring) "?" on types where null is allowed: http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type

This probably needs to depend on us not using the C xpidl compiler, right? Or can libidl handle this syntax? In the meantime, you can express this as an nsIVariant, at some pain on the C++ end.... That said, what would the C++-end API for nullable double even look like? The best I've come up with so far, short of using something like a variant is an inout |double*&| argument that the caller sets to a double on their stack and the callee either writes to or sets to null....

For parameters it would be double* aParam, and for return values double** aRetVal.

(In reply to comment #3) > This probably needs to depend on us not using the C xpidl compiler, right? > Or can libidl handle this syntax? I don't believe libidl can handle this.

> and for return values double** aRetVal. With heap-allocation when a double is actually returned? :(

Why would it need to be heap allocated? But sure, double*& might be better.

> Why would it need to be heap allocated? Well, the alternative is if it's an inout param, with the caller passing in a pointer to a valid double*. But in that case I think double*& is clearer.

Yes, this depends on us switching completely to pyxpidl.

So, we've switched to pyxpidl now. This doesn't seem like it should be particularly hard to implement in XPConnect once we decide what the C++ side should look like.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #10) > So, we've switched to pyxpidl now. This doesn't seem like it should be > particularly hard to implement in XPConnect once we decide what the C++ side > should look like. I'm happy to do the XPConnect bits.

bholley, don't you want to lean the pyxpidl bits also? I don't think we need to mess with extra levels of indirection, just add another argument, e.g. nsresult GetFoopy(double* aResult, bool* aResultIsNull)

(In reply to Benjamin Smedberg [:bsmedberg] from comment #12) > bholley, don't you want to lean the pyxpidl bits also? Not sure if that was intended to be a joke or not, but yeah, sure. ;-) Taking. What's the general priority of this?

Realistically, I don't think this is likely to get done early enough to make it worth doing before we switch over to the new DOM bindings. Once we have a better idea of what they'll look like, we can decide how best to support this. Unassigning for now.