TemplateStringsArray could contain undefined and should always have index 0

Bug Report

🔎 Search Terms

TemplateStringsArray undefined

🕗 Version & Regression Information

• This is a crash
• This changed between versions ______ and 4.4.4
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

Playground link with relevant code 1

Playground link with relevant code 2

💻 Code

function fn (template :TemplateStringsArray) :string {
    return template.raw[0];
}

function fn (template :TemplateStringsArray) :string {
    return template[0];
}

🙁 Actual behavior

1. the first sample throw an error (when "noUncheckedIndexedAccess": true)

2. the second sample doesn’t throw an error (when "noUncheckedIndexedAccess": false)

🙂 Expected behavior

1. the first sample should never throw an error (because 0 index of template.raw will always be a string):

console.log``;// [ '' ]

1. the second sample should always throw an error (because item of template could be undefined):

console.log`\unknown`;// [ undefined ]

[LongTengDao]

Here are the discussion in releated PR https://github.com/microsoft/TypeScript/pull/46826#pullrequestreview-810408126:

DanielRosenwasser:

I’m not really convinced that this change really needs to happen - the | undefined change is taken care of in noUncheckedIndexedAccess, and the tuple change is at best an occasional convenience.

That said, if others want the tuple change, maybe that’s worth discussing - but I’d like to see convincing use-cases when making changes to major types in lib.d.ts

I think this part is too big of a change; I would keep it as string and let people opt into this behavior with noUncheckedIndexedAccess.

LongTengDao:

According to my understanding, noUncheckedIndexedAccess is used to let the user to ensure the index is not out of length, not applicable for the use case that the item value could really be undefined.

People will forget the item of template could be undefined when noUncheckedIndexedAccess: false; and when noUncheckedIndexedAccess: true, people will also forget the item of template could be undefined because they will chronically only confirm the index is not out of length. Because this is really a niche knowledge in ECMAScript 6 that item of template could be undefined, I bet…

And this can make it consistent with TypeScript’s usual behaviors:

const array :string[] = [ '' ];
array[0].length; // this warning depends on whether noUncheckedIndexedAccess is true

const array :( string | undefined )[] = [ '', , '' ];
array[0].length; // this warn even if noUncheckedIndexedAccess is false

const tuple :[ string ]= [ '' ];
tuple[0].length; // this will not warn even if noUncheckedIndexedAccess is true

Are there any downsides to this consistency? (Maybe there a risk I was overlooking)

A use case for the tuple change:

function fn ({ raw } :TemplateStringsArray, ...values :string[]) {
    let ret = raw[0];// no need to write `raw[0]!` here any more. more auto, more safe.
    for ( let index = 0; index<values.length; ++index ) {
        ret += values[index]!;
        ret += raw[++index]!;
    }
    return ret;
}

sandersn:

Let’s move this discussion to an issue. The code change is not likely to be very big, but may change if the issue takes a long time to reach consensus.

[RyanCavanaugh]

TS doesn’t have a way to represent “non-empty array” at the type level, so you get the error

This isn’t quite right; the linked PR uses the tuple type [string, ...string[]] which is capable of representing non-empty string arrays.