support additional properties in RLC

[qiaozha]

fixes #2033

Also fix the boolean/number/string literal type error in the modular layer.

[qiaozha]

As, the VC interface in the below option1 and option2 has the same effect.

interface C {
  prop1: string;
  prop2: boolean
}
// option 1
interface VC extends Record<string, C[]> {}

// option 2
interface VC {
  [prop: string]: C[]
}

And we are using type index like option 2 in current HLC.

Also,the implementation of Record is actually defined to use type index in a way.

type Record<K extends keyof any, T> = {
    [P in K]: T;
};

I will use option 2 to express additional properties in the generated code.

@MaryGao @joheredi let me know if you have other thoughts.

[joheredi]

I would prefer we go with option 1, the main reason is documentation as it is more readable and self documenting than the indexer syntax. They are equivalent and shouldn't cause a breaking change if we move to Record

[MaryGao]

I have no concern if they can express the same functionality. And no strong preference here, both work for me.

[qiaozha]

not sure if it's appropriate to generate Vegetables as

        export interface Vegetables {
          carrots: Record<string, Carrots>;
          beans: Record<string, Beans>;
        }

[qiaozha]

@joheredi in the case of is keyword being used in record to express additional properties,
we currently just drop the model VegetableCarrot generation, use the Record<string, Carrots> to replace it. which has information loss about VegetableCarrot's own properties. And according to Timothee's comment here Azure/cadl-ranch#330 (comment) we should not treat extends and is as the same thing,
One possible solution here is to use indexer syntax here to express additional properties for is Record scenario. like we should generate model VegetableCarrot as

export interface VegetableCarrot {
  [prop: string]: Carrots;
  testProp: Carrots;
}

How do you think ? feel free to come up with different solutions here :)

[joheredi]

I think we should still use Record when setting additional properties

export interface VegetableCarrot {
  [prop: string]: Carrots;
  testProp: Carrots;
}

is identical to

export interface VegetableCarrot extends Record<string, Carrots> {
  testProp: Carrots;
}

But using records is better for documenting. If I understand correctly Timothee's comment is in the context of TypeSpec's is vs extends which I think makes sense in that context and will have implications when emitting OpenAPI, but I also think modeling the TypeScript interface extending record is the best way we can represent it for our customers.

When additional properties are not in the picture then if we saw

model Foo is Record<Carrots>;

we should generate

type Foo = Record<string, Carrots>;

and for

model Foo extends Carrots {
   foo: string;
}

interface Foo extends Carrots {
   foo: string
}

[qiaozha]

it's a little strange to handle is differently based on whether there's extra properties in that model.
Another concern is, this is how we handle is in normal model context.

model Foo is Carrots {
  prop: string;
};
model Carrots {
  prop1: numeric;
};

and we will not generate model Carrots, just generate model Foo like

interface Foo {
   prop: string;
   prop1: number;
}

It's kind of convey an idea to treat is as spread when it's being used in models.

[MaryGao]

approved.