@Andy-MS Note that | undefined has zero effect unless you're compiling with --strictNullChecks. There are undoubtedly many (many!) more places where we'd need to add these, so I'm not sure it makes a lot of sense to add only a few random ones.

@ahejlsberg That's a fair point, but I'm skeptical of whether we will be willing to make an all-at-once refactoring to operate in strictNullChecks. If we don't intend on ever migrating to strictNullChecks, then I'd tend to agree more, but incrementally annotating doesn't seem like a huge problem.

I acknowledge that it can be misleading to add these annotations for external users, but internally we are aware that we're not strictNullCheck-compliant.

My issue with these unchecked | undefined annotations is that they lure you into thinking that functions without the annotations will not accept or produce undefined values--which isn't the case. The fact is that until we switch to --strictNullChecks you can't tell from the annotations whether undefined is a permitted value or not, so I'd rather not pretend that you can.

I've been adding T | undefineds in some places just to help myself keep track of which functions do/don't return undefined. It's better than a comment and once we do move to SNC (which I hope is inevitable) it'll be less work.