This could be an example with a known web framework (ktor? spring?) with a REST API for user registration. The example could also contain an exemple of database validation (error if the username already exists).

There is some inspiration to get from this discussion.

Add support for:

• LocalDate
• Duration
• Period

At the moment, let's focus on the ISO-8601 calendar system.

https://kotlinlang.org/docs/type-safe-builders.html#scope-control-dslmarker

becomes necessary when writing this kind of code:

labels { // this: Validatable<List<String>>
    hasSizeLowerThanOrEqualTo(3) // OK

    each {
        hasLengthGreaterThanOrEqualTo(1) // OK
        hasSizeGreaterThanOrEqualTo(1) // OK BUT SHOULDN'T BE (applied to the list, not to the string)
    }
}

support all classes and interfaces

This is missing, especially for enums and sealed classes.

• isInstanceOf
• isNotInstanceOf

Could be useful for optimizations and for Arrow Either type.

https://plugins.jetbrains.com/plugin/20158-writerside/docs/configure-search.html

The following functions should support nullable iterables:

public operator fun <T> Validatable<Iterable<T>>.iterator(): Iterator<Validatable<T>>

public inline fun <T> Validatable<Iterable<T>>.each(block: Validatable<T>.() -> Unit)

Currently, the following code doesn't work, each isn't callable:

Validator<List<Any>?> {
    each { /* ... */ }
}

It's a bad example, we should stick to query a database.

hasNoDuplicates

Hello
The following library is a complete validation library but unfortunately not updated.
Please check it out and use it.
​https://github.com/valiktor/valiktor

According to Library creators' guidelines, we should stop using data classes in the public API.

Impacted classes:

• library/src/jvmMain/kotlin/dev/nesk/akkurate/Configuration.kt
• plugin/src/main/kotlin/dev/nesk/akkurate/ksp/ValidateAnnotationProcessorConfig.kt

Linking to the API reference is not enough because all the constraints are under the same package, its a mess to explore. We should do like Symfony or Laravel, and list all the constraints categorized by types in the documentation.

@Validate
data class Book(var title: String)

should produce:

/**
 * [Validatable] accessor of [Book.title]
 */
public val Validatable<Book>.title: Validatable<String>
  @JvmName(name = "validatableBookTitle")
  get() = validatableOf(Book::title as KMutableProperty1)

/**
 * [Validatable] accessor of [Book.title]
 */
public val Validatable<Book?>.title: Validatable<String?>
  @JvmName(name = "validatableNullableBookTitle")
  get() = validatableOf(Book::title as KMutableProperty1)

instead of:

/**
 * [Validatable] accessor of [Book.title]
 */
public val Validatable<Book>.title: Validatable<String>
  @JvmName(name = "validatableBookTitle")
  get() = validatableOf(Book::title as KProperty1)
//                                     ^ cast error

/**
 * [Validatable] accessor of [Book.title]
 */
public val Validatable<Book?>.title: Validatable<String?>
  @JvmName(name = "validatableNullableBookTitle")
  get() = validatableOf(Book::title as KProperty1)
//                                     ^ cast error

• we sould ignore all private/protected properties
• we should generate accessors for internal/public properties
• a property can be public in a private class, we should be careful with this
• the accessor should have the same visibility than the property
• the user should be able to override the visibility of the whole accessors, to force them being internal for example, to avoid leaks into the public API

This is not necessary and it was left unintentionnally.

Describe the bug
I'm defining custom constraints and there seems to be no easy way to test them. In the following example, I'd like to create a Validatable<String>, but without the helpers defined in the _test package, it's hard to do because the ConstraintRegistry class is internal.

fun Validatable<String>.isValidTimeZone() = constrain {
    kotlin.runCatching { TimeZone.of(it) }.isSuccess
} otherwise {
    "Should be a valid time zone"
}

Expected behavior
Would it be possible to expose the helper functions, maybe in a test library so that it's possible to unit test the custom constraints?

fun "test_time_zone_constraint" {
  assertTrue(Validatable("America/New_York").isValidTimeZone().satisfied)
}

Thanks!

Hi
Thank you for your helpful library.
I want to use this library in shared module in kotlin multiplatform project but it doesn't support kotlin multiplatform.
Can you work on it?

CharSequence:

• hasLengthEqualTo, hasLengthNotEqualTo
• isBlank, isNotBlank
• regex with isMatching, isNotMatching

All collections:

• isEmpty, isNotEmpty
• hasSizeEqualTo, hasSizeNotEqualTo
• isContaining, isNotContaining

Due to a bug in Kotlin's compiler, we had to add a unnecessary cast in the generated code. However, when using Akkurate in another project, this could generate a warning from the compiler.

We should add a @Suppress annotation to those casts.

The ConstraintViolation has path and message, which is sufficient for most cases.

But it is not the most straightforward design if I need to pinpoint on the exact constraint being violated and act on it. For instance, to pick out a particular constraint violation and throw an alternate Exception instead of the generic Exception.

Currently, to workaround this limitation, there are possibly two ways:

• Override the path using the withPath { absolute("some_identifier") } DSL
• Override the message using the otherwise { "some_identifier" } DSL

The first workaround loses the path in a meaningful way. And the second workaround loses human readable messages.

Is it possible to add a third field of metadata: Map<String, Any> to ConstraintViolation, so that user can freely attach whatever metadata they need to the violation instance.

Possible DSL design:

val validate = Validator<Data> {
   fieldOne.apply {
      shouldNotBeEmpty()
      constraint { it.meetsCustomCondition() } withMetadata { mapOf("key" to "customErrorKey1") }
   }
}

Then, when analyzing the ConstraintViolation:

fun handleViolation(cv: ConstraintViolation) {
   if (cv.metadata["key"] == "customErrorKey1")
      throw CustomError(cv.message)
  throw FallbackError(cv.message)
}

We could provide some conditional helpers :

• ifNotNull
• ifInstanceOf

Instead of:

if (prop.unwrap() != null) prop { // this: Validatable<SomeClass?>
    constrain { it?.someBool == true }
}

we could write:

prop.ifNotNull { // this: Validatable<SomeClass>
    constrain { it.someBool }
}

We avoid calling unwrap, the receiver is automatically defined, and it's no longer nullable.

Some helpers unrelated to type casting could be useful too:

• ifNotEmpty (CharSequence and iterables)
• ifNotBlank
• ifNotNullOrEmpty
• ifNotNullOrBlank

There might be some use cases to manually call the plugin compiler. Let's make its API public and ensure its explicitly defined.

It could be useful to transform a value before validating it, for example:

Validator<String> {
    this.map { it.trim('.') }.isNotBlank()
}

By "transforming" the value, the path remains the same, until overridden by withPath.

Essentially, it would work like Optional.map() in Java, or Either.map() with Arrow, but instead of returning an Optional or an Either, it returns a Validatable.