Add "combine" or "merge" operator for models

[johanste]

Something that I have missed is the ability to combine models outside of spread operators. One example of a (unrelated) language is jsonnet's object combine operator (see inheritance and nested field inheritance the sections).

To illustrate a bit what I'm thinking:

model Base {
  id: string;
  etag?: string;
  apiVersion: string;
}

model Overrides {
  id: int32;
  description?: string;
  apiVersion: never;
}

model Combined is Base + Overrides;

/*
// Resulting model:

model Combined {
  id: int32;
  etag?: string;
  apiVersion: never;
  description?: string;
}
*/

As indicated, the resulting model is not a subtype of either operands, the order of attributes could be preserved (although there is an argument to be made that overriding attributes should move later), decorators (not shown) are not merged etc.

I can think of a couple of places in azure core where this would be useful and simplify our life.

Playground Link

[timotheeguerin]

is the goal here not simply just have multiple model is

[johanste]

I don't think so. I wouldn't expect decorators on Base or Overrides to be applied to Combined. But I do want the property conflicts that would result in doing:

model Combined {
  ... Base;
  ... Overrides;
}

...with last-in-wins semantics...

[bterlson]

I am missing something obvious here, but... how is this different from spread?

[timotheeguerin]

with spread you cannot override properties, here proposal is to have something that would behave like TS object spread

[bterlson]

Ahh right. I don't remember why we made our spread not allow duplicates, but is that something we could change also? I am allergic to adding yet another composition mechanism.

[timotheeguerin]

Yeah I think the one thing though is that right now A & B and {...A, ...B} are exactly the same, I feel like A & B shouldn't be overriding(it merge in typescript)

[timotheeguerin]

Noting that this behavior of overriding is not possible in the typescript type system( as far as I remember), you can override object properties this way but not interface memebers

[bterlson]

The type system does allow it in the sense that runtime spreads do the override calculations in the type system, but you can't declare such types (there is an issue tracking it that has been open for some time).

If the only real justification for spread not overriding previous properties is to maintain alignment with intersection, then I would be fine updating spread to override. Intersection should probably intersect same-named properties too, and that would definitely not make sense for spread...