Repository navigation
Template strings: Negated match #49867
Description
Suggestion
📃 Motivating Example
Strings, in particular key names, sometimes affect types based on the format of the string, most commonly with prefixes. One such example is the recent W3C Design Tokens spec which uses a $ prefix to reserve key names like $description and $type.
Right now it's possible to create a positive match such as:
type CssCustomPropertyName = `--${string}`But there's no way to create a negative match. Or in regex terms:
(?!--) # not `--`The goal here wouldn't be to recreate all the functionality of regex/parsing, it would be to handle the stringy-typing sometimes seen in JavaScript (including within official web specifications).
⭐ Suggestion
Note: This is one option, I'm not particularly tied to it and could suggest alternatives if this is not workable.
Expose, in a limited capacity, the not operator (#29317) so that it can be used to filter strings.
type Name = string & not `--${string}`
let a: Name = "--x" // err!
let b: Name = "--" // err!
let c: Name = "x" // ok
let d: Name = "x--" // ok
let e: Name = "-x" // okThere is an existing PR adding a not operator, but has been long stalled on expected behavior. But maybe just this one piece could be added and slowly expanded from, if desired, later.
💻 Use Cases
The W3C Design Tokens spec does not allow token/group names starting with a $ or containing any of the characters .{}.
Using negated string matches, you could correctly type this:
type Name = string & not `$${string}`
interface Group {
$description?: string;
$type?: string;
[key: Name]: Token | Group
}The closest you can get to this today is:
type LowerAlpha = 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z'
type UpperAlpha = Uppercase<LowerAlpha>
type Numeric = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
type AlphaNumeric = LowerAlpha | UpperAlpha | Numeric
type SafeSymbols = "-" | "_" | " "
type NameStart = AlphaNumeric | SafeSymbols
type Name = `${NameStart}${string}`
type Group = {
$description?: string;
$type?: string;
} & {
[key in Name]: Group
}
let group: Group = {
$description: "",
$type: "",
"my cool name": {}
}🔍 Search Terms
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.
- String
- Negated
- Pattern
- Regex
- Regular Expression
- Not
- Prefix
- Suffix
✅ Viability Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Activity
RyanCavanaugh commentedon Jul 12, 2022
If we presuppose
not Tas the type negation operator, then it's tempting to support this (initially) viawhich we can parse only in the context of a
${ ... }placeholder. Thoughts?jamiebuilds commentedon Jul 12, 2022
Ryan Cavanaugh (@RyanCavanaugh) That was my initial idea, but presumably the type
not "--"also matches an empty string"".So given the string
"--abc"and the template type`${not "--"}${string}`you could argue:${not "--"}matches""${string}matches"--abc"Negating an entire pattern is less ambiguous:
RyanCavanaugh commentedon Jul 12, 2022
I think the empty string matching argument is correct under one interpretation of how that should work. I guess the problem is that if
not "x"exists, then${not "x"}needs to mean something but I agree it's super unclear what given that""is a valid${string}.Is it as simple as for
${not ("a" | "bb")}, then the entire containing template is a not-match ifs.indexOf("a") === 0 || s.indexOf("bb") === 0? But then it's unclear how many characters to consume.I feel like we have to handle it at a placeholder level since the template strings can already be nested, so we'd have to have answers for what it means to write
jamiebuilds commentedon Jul 12, 2022
Maybe someone else does, but I don’t have any particularly more complicated cases than the one I mentioned. So I would accept a solution that simply doesn’t allow you to interpolate negated strings into other template types.
fatcerberus commentedon Jul 12, 2022
w.r.t. the empty string issue, isn't it already the case that when there are consecutive placeholders, each one except for the last must consume at least one character (in order to enable recursive
${head}${tail}style template string types, IIRC)? So something like${not "--"}${string}shouldn't be an issue.RyanCavanaugh commentedon Jul 12, 2022
Consecutive placeholders will consume one character at a time if present, but will still produce
"":is considered to be effectively
"m", "m", ""fatcerberus commentedon Jul 12, 2022
Right, but the empty string can only be produced by the final one unless there aren't enough characters to begin with. That's why I said "except for the last" above. In other words,
${not "--"}${string}should never be able to produce, e.g.,"", "--foo"jamiebuilds commentedon Jul 14, 2022
Thinking about this more, I wonder if a lot of the concerns about the original
notproposal could be addressed by starting with a more limited feature only for primitive types and literals:true,0,"",`${}`, etcnull,boolean,number,bigint,string,symbol)any,never,unknown, objects, etc)From the original pull request (#29317), from what I can gather, these were the primary concerns: (cc Daniel Rosenwasser (@DanielRosenwasser))
Consistency: Can this feature compose with every other feature in TS and get expected results?
Complexity: This is going to have to be considered in every future change to TypeScript, and could get in the way of more useful features.
Use cases: A lot of the use-cases for this feature can already be implemented in other (less declarative) ways
Flexibility around primitive and literal types is the main use case that I'm concerned with, and I think I would actually prefer if TypeScript told me when I was trying to do silly stuff like
not anybecause that sounds like a mistake to me.matthew-dean commentedon Apr 18, 2023
Why not just allow regex types instead of re-inventing the wheel of regex? There are plenty of use cases. For example, creating a type that only allows a valid CSS hex color as a value is extremely non-trivial.
verikono commentedon Aug 20, 2023
Matthew Dean (@matthew-dean) : Regex would be fricken sensational.
there is a library for this but performance may be problematic:
https://github.com/didavid61202/type-level-regexp