import { type InlineToken } from "./tokens.ts";
export declare const typeBracketDeclarationWords: Set<string>;
export declare const typeBracketOperators: Set<string>;
export declare function beginsTypeBracket(tokens: readonly InlineToken[]): boolean;
/**
 * D55 rule 127.2 / D57 rule 134: which '<' opens a type argument list is a
 * question about position, never about the name in front of it. A whitelist of
 * generic names — the shape this used to have — is blind to `Record<T>` today
 * and to every generic a program declares for itself tomorrow, so the two
 * remaining type positions are read structurally instead.
 *
 * The first is the annotation a ':' introduces (`x: Record<string>` as a
 * parameter, a field, or a `const`), reached by walking back over the words and
 * dots the type itself owns so modifiers such as `readonly` do not hide it.
 * The second is the target of a type alias, where everything right of '=' on a
 * `type` line is type syntax.
 */
export declare function opensAnnotatedType(tokens: readonly InlineToken[]): boolean;
export declare function isTypeAliasLine(tokens: readonly InlineToken[]): boolean;
/**
 * The annotation position is the one type position a comparison also occupies,
 * so the bracket has to prove itself: a type argument list closes on this line
 * with nothing between the brackets but type syntax. `{visible: count < limit}`
 * never closes, and `{ok: a < b and c > d}` carries a word no type argument
 * list can hold.
 *
 * A function type carries its parameter names, so the `:` of `List<(x: number)
 * -> string>` is type syntax too — but only inside the parameter list it names
 * a parameter in. At the top of the argument list a `:` is the one in
 * `{visible: count < limit, other: x > y}`, which is a record and two
 * comparisons, so the paren depth is what separates them.
 */
export declare function closesAsTypeArguments(source: string, start: number): boolean;
/**
 * D90 (compiler-front-15): the type argument list a TypeScript habit puts on a
 * call — `Map<string, number>()`, `id<string>("a")`. VelarScript infers type
 * arguments, so the spelling is always an error and the parser reads it without
 * regard to spacing. The formatter has to read it too: respacing it into
 * `Map < string, number > ()` rewrites the author's line into a spelling that
 * appears nowhere in their source, in exactly the file `velar format` is
 * pointed at while the teaching diagnostic is on screen.
 *
 * The evidence is the parser's (`explicitTypeArgumentsEnd`) minus the same-file
 * generic roster a line-based formatter cannot see: the brackets close on this
 * line with `(` directly behind them, and every `,`-separated argument carries
 * type evidence of its own — so `two(a < Limit, g > (c))`, two comparisons and
 * a working program, keeps its operator spacing. Being narrower than the parser
 * can only cost a respace on a line that is an error either way; it can never
 * change which reading the compiler gives a line, because the parser does not
 * consult the spacing.
 */
export declare function opensCallTypeArguments(source: string, start: number): boolean;
export interface TypeArgumentScan {
    /** The offset just past the closing '>'. */
    readonly end: number;
    /** Every ','-separated argument carried evidence of being a type, and there was one. */
    readonly typed: boolean;
}
export declare function scanTypeArguments(source: string, start: number): TypeArgumentScan | null;
//# sourceMappingURL=types.d.ts.map