When wiring a Mojom-defined interface up to Blink code, I find that it is hard to know if a String I get from Blink can ever be null. The type definition implies that it can sometimes be null. As a result, I think I need to write code like this at every callsite:

  mojom_interface->CallMethod(string.isNull() ? emptyString() : string);

That seems pretty unfortunate.

If null were promoted to empty when passed to a non-nullable field, then it would be a lot simpler.

I agree though that we should be careful here. This could be a choice that we might regret.

I'm also open to the idea of special-casing strings. Maybe objects should work as they do today.

Note: This same issue doesn't apply to WTF::Vector as it does not have a null state.

Yeah, agreed that this is unfortunate.

A few other possible solutions that may also worth considering:

1) use "string?" for fields that we would like to pass WTFString (although in general it seems a little unfortunate to change the mojom type to fit the bindings type)

2) create a NonNullWTFString wrapper (a better name needed...), which can be converted to/from WTFString implicitly. So we can generated bindings like:

virtual CallMethod(const NonNullWTFString& input);

And then call it with a WTFString directly. The conversion will take care of promoting null WTFString to empty.

> virtual CallMethod(const NonNullWTFString& input);

That seems like it would work on the caller side, but Mojom interfaces are also used on the implementation side. It seems like on the implementation side, we'd want CallMethod to take just a "const String&" instead right?

Using "string?" for these seems less satisfying and still leads to having to write code to handle null.

Hmm...

If the implementation is also in blink, I would imagine that the interface is the same. We could support implicit cast from NonNullWTFString to WTFString, so it should have a minimal impact on the implementation code.

I am not super happy with introducing another string type. So far all the solutions seem to have some drawback. :/ I will think harder...

Still seems like a valid request, so triaging as such.

I kind of think that if we treat a null WTFString as empty in any context, we must treat it as empty in every context. So e.g. even if passed for a "string?" field, the field should take on the value of an empty string rather than null. 

Otherwise this is bound to be very confusing behavior.