type identifier should not trigger an parsing error when part of an assertion

[jean-michelet]

Will fixes #58248

I'm not sure if there are any other cases I've missed. I'll take a closer look this week, but feel free to give feedbacks 🙏

This should be ok:

const type = 'x';

type satisfies string;
type as string;

// EDIT: the following example is obsolete
// const interface = 'x';
// interface satisfies string;
// interface as string;

[whzx5byb]

interface satisfies { } will be ambiguous: Does it define an empty interface named satisfies? Or does it validate that the type of a variable named interface matches {}?

Also, considering interface is already a reserved word in strict mode, I don't think it's necessary to eliminate the parsing error for interface.

[jean-michelet]

interface satisfies { } will be ambiguous:

Oops, indeed.

[DanielRosenwasser]

The more I think about it, I realized this is a bit of a tricky problem because the look-ahead is unbounded. You can write

type satisfies <T>() => T

And from the parser's point of view, when it sees

type satisfies <

it needs to make a call of whether this is going to be a type alias or a satisfies expression.

So what I would do is keep the special-casing for as and satisfies and make sure we have tests for things like

// These were written with the expectation of parse errors.
// We expect the parser to try constructing a statement expression
// with 'satisfies' and 'as' expressions.

type satisfies<T> = T;
type as<T> = T;

and

// These should be parsed as statements
// with 'satisfies' and 'as' expressions.

type satisfies <T>() => T;
type as <T>() => T;

[DanielRosenwasser]

It really feels like this function should have been left as-is, and the look-ahead should have been done after calling this function specifically for the type keyword.

It also might be the case that you don't actually need to special-case as and satisfies, you can just do an unconditional look-ahead. But I might have to think about that.

[DanielRosenwasser]

The name of a type alias isn't always immediately followed by an =, so I don't think this specific look-ahead is enough.

See the comment I'm leaving in my review.

type satisfies<T> = T;

[DanielRosenwasser]

Also, like @whzx5byb mentioned, you should add an interface satisfies/interface as test to ensure there's no regressions

[jean-michelet]

I hope I understand what you have in mind.
I've left comments to make it clear what I understand needs to be done.

[jean-michelet]

Make sure there are no regressions concerning the interface keyword.

[jakebailey]

Can you explicitly test interface satisfies { }?

[jean-michelet]

Type parameters were not parsed.
This test ensures these are considered type aliases.

[jean-michelet]

Make sure that assertions with type parameters are parsed as assertions.

[jean-michelet]

Do you think this part should be in a proper function?
We could return something like this:

return nextTokenIsIdentifierOnSameLine() && someNameToExplainsWhatIsDoneRegardingSatisfiesAndAs()

[jakebailey]

This feels like it would be pretty wasteful, but I suppose that people can't write this code today anyway and it'd only be paid for as and satisfies.