Pure function validators

[junaid1460]

Search Terms

Custom type validators, pure function validators

Suggestion

having a defined way to document shape / value of a generic type like string , number. This could be a static compile time feature or it can be dragged into runtime.

Use Cases

Avoiding mistakes while creating cache keys
Validators for URLs in form of string
Validators for range

Examples

function url(urlStr: string) {
   // Test ur, if okay do nothing, else return error with examples
}

function ipAddress(ipString: string) {
   // Test ur, if okay do nothing, else return error with examples
}

const endPoint: string & ( url | ipAddress ) = "0.0.0.0"

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[MartinJohns]

I'd say this is a duplicate of #202 (combined with type guards). The cases "url" and "ip address" could also be solved by #6579.

[junaid1460]

yes, but regex makes it harder to read, also this looks more generic can be applied to any type, regex could be kind of validator within

I mean

const port: number & range(8000, 9000) = 8001

where range could give a curried function that can accept type 'number' which is 8001

[junaid1460]

This could be just compiler internal implementation for most of the use cases

[awerlogus]

If we'll drag it into runtime, it will give us ability to create programs with undefined behavior

For example:

const lessThanHalf = (num: number) => num < 0.5

const a: number & (lessThanHalf) = Math.random()

But if we'll check it statically, it will not be possible even to compile this code because the type number, returned by the random function, will be not assignable to the type number & (lessThanHalf).

So, we can just add predicate to the type of value after checking the value with it.

const lessThanHalf = (num: number) => num < 0.5

const num = Math.random()

if(lessThanHalf(num)) {
// num is `number & (lessThanHalf)` here
} else {
// num is `number` here
}

But I still have a lot of questions:

1. How about functions with different names, but which are doing the same?

const a = (num: number) => true
const b = (num: number) => true

const c = 0

if(a(c)) {
  // Should this be valid?
  const d: number & (b) = c
}

2. Should predicates be pure? Why?

3. Can we use only named functions or anonymous too?

If yes, how should the type of variable b look like?

const a = 0

if(((num: number) => true)(a)) {
  // What is the type of b?
  const b = a
}

If no — don't you think that limiting the checks with named functions only will unnecessarily increase the size of the code?

4. What about generic predicates?

5. How to handle this case?

function a() {
  const b = (n: number) => true

  return (n: number & (b)) => n
}

const c = a()

The type of c refers the scope that is not accessible from the scope where c is declared

---

IMHO: the approach proposed in this issue adds much more problems than it solves

[junaid1460]

• I know lambdas are cool, Goal is to improve readability and self document the code
• Also I accept nobody can stop a newbie from bad variable names.
• Let's accept the fact that nobody reads comment, just expects it in PRs. But comments are good with IDEs that can deal with all sort of convention.

[junaid1460]

• Yes predicates should be pure, to make it possible to statically evaluate and expect same result for a input any time
• For 5, I guess you are missing the main feature of typescript type inference, as along as validator b is pure, we can copy it anywhere. Pure also means, no closure.

[junaid1460]

And mainly the validator api should have a design strategy where we decide what's the signature of predicate should be, It should never be any function. Every api needs to have schema and should be predictable.

[junaid1460]

Everything that has schema should be statically assertable, We define conventions in our codebase that's documented in a cornered file
example :

• cache keys that have defined scheme for it, we know it, but we do not enforce it.
• Ranges, we choose a random range for our operation and start using it every where but we do not know how to enforce/ educate a new employee about the convention other than KTs for weeks
• Benefits of this is much more, having a simple compiler that asserts lua scripts without having to exploit the code base with 100 different kinds of files
• able to assert sql

[RyanCavanaugh]

I can't tell from this proposal whether you're proposing that TypeScript evaluate ipAddress at compile time (which we're not going to do), or if you're proposing that TypeScript insert code into the JS emit to cause ipAddress to be evaluated at runtime, which we also wouldn't do.

[junaid1460]

I am proposing that literals can be evaluated at compile time @RyanCavanaugh . Node mostly runs on api side and does lots of query/scripts which can be statically evaluated.