Cooking raw literalSegments?

[hemanth]

Would we have to support the below?

String.cooked({raw:[]})

As of today, String.raw does the below:

[bathos]

I'm not sure what you mean exactly by supported. If you mean "what would happen," the current steps would produce the empty string normally, for the same reason String.raw would today if the raw property returns a random non-array object:

String.raw({ raw: {} }); // "", because LengthOfArrayLike is, barring prototype tampering, 0

If you mean supporting in the sense of deriving the cooked string value from the raw strings if they're present (and presumably falling back on just using precooked if not), that's pretty interesting, though its utility isn't clear to me and it seems less analogous to String.raw, which trusts that its input will behave like a template array result.

[jamiebuilds]

I guess the question is more, String.raw({ raw: ["foo", "bar"] }, []) works because there's no validation to ensure the inputs come from a template string, should String.cooked({ raw: ["foo", "bar"] }, []) have defined behavior?

[hemanth]

Yes, I was alluding to what @jamiebuilds mentioned ^

[bathos]

My reasoning for why I’d expect raw to not be accessed or read from:

• the template object “contract” is roughly “array of cooked strings with raw property holding array of raw strings"
• String.raw concatenates the raw-strings array
• String.cooked concatenates the cooked-strings array

Since raw “trusts” that this contract is followed, it seems like cooked would too, in which case cooking the raw template values again is redundant. It might enable some interesting things (almost a rough String.parse analog for Number.parseFloat etc for safe escape resolution without eval?), though it would probably be awkward in that role vs a more purpose-built API.