Introducing base::Optional<T>

[Mounir Lamouri]

Hi chromium-dev,

base::Optional<T> has just landed. It is an implementation of C++17
std::optional<T> with minor changes.

If you've been interested to use Nullable/Optional/Maybe types in
Chromium, you should now be able to do so. If you have implemented your
own type (like headless/public/util/maybe.h), you can now deprecate it
and switch to the base/ type.

To know more about what base::Optional<T> is meant to do, how it works
and when you are expected to use it, please have a look at the
documentation:
https://chromium.googlesource.com/chromium/src/+/master/docs/optional.md

Thanks,
-- Mounir

[Avi Drissman]

Excellent!

This appears to obviate the need for the special case base::NullableString16 then. Are there plans to follow up and remove it in favor of base::Optional<base::string16> ?

Avi

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Dana Jansens]

On Tue, Apr 19, 2016 at 7:07 AM, Avi Drissman <a...@chromium.org> wrote:

Excellent!

This appears to obviate the need for the special case base::NullableString16 then. Are there plans to follow up and remove it in favor of base::Optional<base::string16> ?

Yes, I would like to delete NullableString16. Assistance welcome.

[Dana Jansens]

On Tue, Apr 19, 2016 at 1:07 PM, Dana Jansens <dan...@chromium.org> wrote:

On Tue, Apr 19, 2016 at 7:07 AM, Avi Drissman <a...@chromium.org> wrote:

Excellent!

This appears to obviate the need for the special case base::NullableString16 then. Are there plans to follow up and remove it in favor of base::Optional<base::string16> ?

Yes, I would like to delete NullableString16. Assistance welcome.

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=604860 for this work.

[Marijn Kruisselbrink]

A question about the base::Optional documentation: in the "When no to use?" section the documentation explains that generally you shouldn't use it as a function parameter and instead keep using T* for optional arguments. That all sounds reasonable. But actually writing code that way makes it really annoying when a caller that has a base::Optional<T> wants to call a method that accepts a T* (especially if that method or constructor then goes ahead and wraps it back up in a base::Optional<T>).

Unless I'm missing something, this would require code to look something like this:

base::Optional<Foo> my_foo;

new SomeClass(my_foo ? &my_foo.value() : nullptr);

class SomeClass {

  SomeClass(Foo* foo) : m_foo(foo ? base::make_optional(*foo) : base::nullopt) {}

  base::Optional<Foo> m_foo;

};

So is this a case where having a base::Optional<T> constructor argument might actually make sense? Or is this the code we're supposed to be writing. Or am I missing something that makes this code less ugly?

[Dana Jansens]

Yeah, that looks like how I would write it, or assign m_foo in the constructor body "if (foo) m_foo = *foo;" which is less writing.

Is this a real example? I'm not sure how contrived it is to take an optional pointer and copy that into a concrete member.

Also, how much are you saving here by using Optional and avoiding constructing Foo when Foo* is null? It might be simpler code to just store a bool or the original pointer (instead of copying it?).

[Marijn Kruisselbrink]

Yeah, maybe the answer is indeed to just use unique_ptr for situations like this. It certainly makes the code simpler. It just seemed conceptually base::Optional better expressed what I was trying to do.