Interface Requests as fields of a struct

[Mitch Rudominer]

As part of a project to re-implement the mojom bindings compiler I am writing a specification for the mojom language.

The current state of the language specification is a little fuzzy around the edges because certain edge case questions are determined not in the core parsing logic but rather in the generators for individual languages and different languages may answer the validity question differently.

As one example consider the question of whether or not a field of a struct is allowed to be an interface request. This is not decided by the common parsing logic and it is disallowed by the c++ generator but allowed by, for example, the Dart generator.

I don't think it makes sense to allow different languages to decide this question differently. The mojom spec should either allow it or not.

I can't think of a good reason to allow this particular option and I would like to excise it from the specification and enforce that in the new compiler. Please tell me if you know of a reason why I am wrong about that.

I'm not sure how many discrepancies like this will pop up. If it turns out to be a lot then I will have to find a more scalable way to make the decision than sending an e-mail like this to mojo-dev.

- Mitch

[Darin Fisher]

Should there be a difference in capabilities between f(a,b,c) and f(S) where S is a struct with fields a, b and c? I would think the answer should be no.

[Mitch Rudominer]

On Fri, Jul 31, 2015 at 2:56 PM, Darin Fisher <da...@chromium.org> wrote:

Should there be a difference in capabilities between f(a,b,c) and f(S) where S is a struct with fields a, b and c? I would think the answer should be no.

Yeah ok that's a good argument.