Another option would be for mojo to generate clone traits for any interface Foo that defines a Clone(Foo& foo) method, as that seems to be what most cloneable interfaces have ended up defining...

I think it would be reasonable to define an InterfaceTraits concept with an optional ClonePtr as its first supported trait.

Hello Ken,
Could you please give an example of InterfaceTraits usage? I think I understood the problem described in the ticket (FetchAPIResponse::Clone() cannot call the default constructor of InterfacePtrInfo), but am not sure what needs to be changed.
Thanks!

To be clear, I'm not necessarily suggesting that this is something we should bother doing. It seems like a small niche concern to me, and there are other things that can't be cloned (e.g. raw message pipe handles, data pipe handles, certain types of shared buffer handles).

IF we did anything, I think it would be to allow users to define a specialization like InterfaceTraits:


  template <>
  struct InterfaceTraits<foo::mojom::Foo> {
    static foo::mojom::FooPtrInfo Clone(const foo::mojom::FooPtr& foo) {
      foo::mojom::FooPtrInfo clone;
      foo->Clone(MakeRequest(&clone));
      return clone;
    }
  };

and this would then be used by any generated Clone() method for a struct which contains a FooPtr.

And actually the tricky part would be knowing at generation time whether the Foo interface actually has a Clone trait, since we don't want to generate a struct's Clone at all if it's not fully cloneable, e.g. if it has a FooPtr field and Foo does not define a way to be cloned.

Soooo... I guess we'd still at least need a [Cloneable] attribute or something on the mojom interface definition:

  [Cloneable]
  interface Foo {
    // ...
  };

The attribute would cause certain uses of Foo in mojom to generate code which will fail compilation if InterfaceTraits<Foo>::Clone isn't defined.

> And actually the tricky part would be knowing at generation time whether the Foo interface actually has a Clone trait, since we don't want to generate a struct's Clone at all if it's not fully cloneable, e.g. if it has a FooPtr field and Foo does not define a way to be cloned.

Not sure what you mean with that? As far as I know today you always generate a struct's Clone, relying on templates to make sure it isn't instantiated unless somebody uses it, i.e. this comment in the generated bindings:

// Clone() is a template so it is only instantiated if it is used. Thus, the
// bindings generator does not need to know whether Clone() or copy
// constructor/assignment are available for members.
 

Ah sorry, I was thinking of Hash, which is a similar situation, except we
do filter it at generation time. We could (should?) be doing the same for
Clone.

I guess I do see the point of suggesting "CloneTraits" as the right way to
slice this, since we can at least then have a consistent way of expressing
cloneability across all types of things. Who knows, maybe someone will
someday find a way to rationalize "cloning" an InterfaceRequest<Foo> too.