IssueTracker

I highly support this, this way every current FormGroup subclass can define only the functions it needs (Everything besides Address can get rid of the AutofillType API and of the app_locale parameters, many classes could also get rid of the VerificationStatus API, etc.)

AutofillProfile could then implement a GetDataForType(FieldType) -> absl::variant<Address, NameInfo, ...> and provide the current API with visit calls instead of polymorphism.

Relevant prior discussion: https://chromium-review.googlesource.com/c/chromium/src/+/6197978/comments/3ac57e7a_d168059a

Re the discussion from #comment3:

It's true that the polymorphism isn't used, but isn't desirable to have a consistent interface among data model classes regardless?

I agree an interface has some appeal as a tool to define a contract even if the polymorphism isn't needed. But I'd say in C++ it's not worth the cost that comes with inheritance. By cost I mean the general sketchiness, the code-search complexity, and very concretely that we can't default operator==() safely (which is what led me to file this bug). In the case of the SingleFieldFormFiller interface, removing an "unused" interface was I think positive in every way (issue 374266445).

I'd rather use a concept plus static_assert to express that multiple classes define the same API, if we don't need run-time polymorphism.

FormGroup gives us a consistent way to read/write data from/to all Autofill objects.

In my view*, FormGroup is only on the surface a "consistent way to read/write data from/to all Autofill objects". I think it fails at defining a clear contract that's uniformly met by the implementations because there are so many similarly named functions, some of which may be useless because they don't use some parameters. As a result, in my experience, I have to look at every implementation anyway to figure out what it does. And the implementation inheritance IMO makes this a lot annoying because I'm always afraid that I'm missing some override.

This is useful by itself, but also enables easy composition of FormGroups.

It looks to me like we can do the same easily with absl::variant, but I haven't tried it.

*: Admittedly I haven't used FormGroup that much yet, but I've found myself looking at it on code search a lot of times over the past couple of weeks.

From the discussion in comment #3:

If we've already gathered some attention around this important topic, I will create a design document to discuss possible solutions. I think we agree that the FormGroup class is not well designed, but we have different ideas about what to do with it.

Piotr, did you already have a chance to create such a doc?

I haven't had a chance to create the design document yet, but I still intend to do so. Given that this topic is still actively being discussed and raised, I'll increase the priority of creating it.