IDL: make optional arguments (without default) explicit sometimes

IDL: make optional arguments (without default) explicit sometimes

If an optional argument without default is followed by at least one
optional argument with a default, call the C++ implementation with
a parameter of the type Optional<T> (T=the argument's C++ type) that
contains a bool that represents whether the argument was missing,
rather than calling the C++ implementation with fewer parameters.

In the IDL code generator and templates, this is called an "explicit
optional" argument.

BUG=258153

[Jens Widell, 2014-06-17 09:53:37]

Please have a quick look at this.

This is just a proof-of-concept (at this point) of one way of dealing with
optional arguments without defaults. I haven't tested it beyond running the
scripts and looking at the generated code. I'm quite sure it breaks compilation.

This is based on https://codereview.chromium.org/335113002/.

https://codereview.chromium.org/337343002/diff/1/Source/bindings/tests/result...
File Source/bindings/tests/results/V8TestInterfaceConstructor.cpp (right):

https://codereview.chromium.org/337343002/diff/1/Source/bindings/tests/result...
Source/bindings/tests/results/V8TestInterfaceConstructor.cpp:75: bool
optionalDictionaryArgMissing = false;
The code generated here is not correct; this new local is set but never used,
for instance. My new logic interacts poorly with either Dictionary special
casing, or [Default=Undefined], I think.

https://codereview.chromium.org/337343002/diff/1/Source/bindings/v8/Optional.h
File Source/bindings/v8/Optional.h (right):

https://codereview.chromium.org/337343002/diff/1/Source/bindings/v8/Optional....
Source/bindings/v8/Optional.h:24: Optional(const Optional<U>& other)
This operator might be useful (or not work at all) when dealing with for
instance string arguments. In the generated code, they will be of type
V8StringResource<>. In the C++ implementation, they argument will typically be
either WTF::String or WTF::AtomicString to which V8StringResource<> can be
converted.

So the idea would be that the generated code calls the function with
Optional<V8StringResource<> >,  and the C++ implementation is declared to take
either Optional<String> or Optional<AtomicString>, and automatic type conversion
takes care of the rest.  I don't know that this works, since I haven't tested
it.

[haraken, 2014-06-17 11:06:19]

Commented in https://codereview.chromium.org/312683005/.

[Jens Widell, 2014-06-23 15:32:16]

I've updated this patch to be more complicated. This is mostly a "what would it
take to do X" experiment at this point. It's certainly hacky and incomplete, but
it doesn't actually break compilation currently.

The approach here is: use Optional<> for *all* optional arguments without
defaults, but extend it to convert automatically into basic C++ types (those
that existing C++ implementations actually take as arguments) in a way that
handles missing in some type-specific way (i.e. null pointer/null string). If a
C++ implementation wants to, it can declare its argument to be Optional<X> and
handle missing explicitly.

I haven't examined its impact on performance or footprint. Could be neutral (if
all this templatery is optimized away) or completely unacceptable. :-)

[haraken, 2014-06-23 16:21:42]

On 2014/06/23 15:32:16, Jens Lindström wrote:
> I've updated this patch to be more complicated. This is mostly a "what would
it
> take to do X" experiment at this point. It's certainly hacky and incomplete,
but
> it doesn't actually break compilation currently.
> 
> The approach here is: use Optional<> for *all* optional arguments without
> defaults, but extend it to convert automatically into basic C++ types (those
> that existing C++ implementations actually take as arguments) in a way that
> handles missing in some type-specific way (i.e. null pointer/null string). If
a
> C++ implementation wants to, it can declare its argument to be Optional<X> and
> handle missing explicitly.
> 
> I haven't examined its impact on performance or footprint. Could be neutral
(if
> all this templatery is optimized away) or completely unacceptable. :-)

What's your proposal about Optional<> and Nullable<>? Are you planning to
introduce both?

(As discussed in a separate bug, regarding Optional<> and Nullable<>, we don't
want to introduce complexity just for making the implementation 100% conformant
with the IDL spec. We want to introduce complexity as much as needed to support
98% of real IDL files.)

[Jens Widell, 2014-06-23 17:26:41]

On 2014/06/23 16:21:42, haraken wrote:
> On 2014/06/23 15:32:16, Jens Lindström wrote:
> > I've updated this patch to be more complicated. This is mostly a "what would
> it
> > take to do X" experiment at this point. It's certainly hacky and incomplete,
> but
> > it doesn't actually break compilation currently.
> > 
> > The approach here is: use Optional<> for *all* optional arguments without
> > defaults, but extend it to convert automatically into basic C++ types (those
> > that existing C++ implementations actually take as arguments) in a way that
> > handles missing in some type-specific way (i.e. null pointer/null string).
If
> a
> > C++ implementation wants to, it can declare its argument to be Optional<X>
and
> > handle missing explicitly.
> > 
> > I haven't examined its impact on performance or footprint. Could be neutral
> (if
> > all this templatery is optimized away) or completely unacceptable. :-)
> 
> What's your proposal about Optional<> and Nullable<>? Are you planning to
> introduce both?

If we go for this kind of approach, I definitely think we should formulate it
such that it handles both optional/missing and nullable/null for attributes.

> (As discussed in a separate bug, regarding Optional<> and Nullable<>, we don't
> want to introduce complexity just for making the implementation 100%
conformant
> with the IDL spec. We want to introduce complexity as much as needed to
support
> 98% of real IDL files.)

As promised, I will investigate what current IDL files appear to need in this
area. (Until I report on that, this patch in particular is not an actual
proposal, just a FYI/WIP.)

By coincidence, while testing the new version of this patch, I picked a random
optional numeric attribute to convert into being Optional<T> in the C++
signature. The one I picked was CanvasRenderingContext2D.fillText's trailing
"optional unrestricted float maxWidth" argument. It turns out that this method
is implemented in C++ as two overloads (necessarily) both calling an internal
function that has maxWidth as a float (value) and a bool (!missing). IOW, this
function wants to know if the argument was missing, and could meaningfully use
Optional<> to know that. (Overloading works fine too in this case, of course.)

This change could replaces [Default=Undefined], by making it the default. 357
lines in 81 different IDL files contain "Default=Undefined". But it's possible
many of them should really be replaced with other actual default values.

[Jens Widell, 2014-06-24 08:52:51]

On 2014/06/23 15:32:16, Jens Lindström wrote:
> I haven't examined its impact on performance or footprint. Could be neutral
(if
> all this templatery is optimized away) or completely unacceptable. :-)

With GCC the stripped binary's size shrinks by 10 kB or so, with this patch +
all uses of [Default=Undefined] in IDL files removed.