Validation integrated into language

[gulshan]

The basic idea of validation integrated into language includes but not limited to-

• A data type being able to indicate it can be or should be validated.
• A method can indicate it requires validated data for some parameters.
• A member method or property can indicate that it can only be called on valid objects.
• Compiler helping the programmer to keep track of validation, like it would be doing for nullability in C# 8.

I'm not going for concrete syntax proposals now, only stating the abstract idea.

[stakx]

I understand where you're coming from: data validation is important, but often hard to do right, so it'd be nice to get all the help we can. But:

I'd say data validation is a problem that can be solved sufficiently well with proper design (e. g. defining types that perform proper encapsulation / protect their class invariants at all times) and support through dedicated libraries.

I've found that data validation is often context-dependent: Data that may be considered valid for one purpose may be invalid for another. It's probably going to be very difficult building language features flexible enough to express where and when validation is required to happen, and how (according to which set of rules), and what kind of error(s) should be produced for invalid data.

I've seen many different ways of how validation is done; there is no one right way. What looks good in the context of my code / program architecture may be the wrong approach for yours.

In conclusion, I believe data validation is far too complex a topic to be built into the language. This task is perhaps better left to design & libraries, so you can choose one that fits your needs best.

PS: Despite what I just wrote, I do actually like this proposal.

[yaakov-h]

#105

[gulshan]

Method contracts is method centric, as suggested by name. This proposal is type/object centric, goes more with OOP paradigm in my opinion. This may require to keep track of object validation with a state. Method contract will try to keep validation declarative and short. This approach leaves it to the programmer. Nonetheless, both of the ideas may be trying to address the same problem.

[gulshan]

@stakx What I am suggesting is leaving how the data should be validated to the programmer's hand. That can be something like an IValidable implementation. But language can help to keep track when or if data/object has been validated.

If same data is valid in some context in invalid in another, this language integrated approach will encourage to put them them into two separate type, may be one encapsulating/inheriting another. Which will keep the validation context explicit.

[jveselka]

If same data is valid in some context in invalid in another, this language integrated approach will encourage to put them them into two separate type, may be one encapsulating/inheriting another. Which will keep the validation context explicit.

If that is ok for You, then why not just put invalid and valid data in two separate types?

[gulshan]

There are many possible ways to address the problem today. But what I think is, integration of validation into the language will make the life easier for developers. Keeping valid and invalid data in separate types kind of mimics my proposal with current features. But I think it will create a big disturbance in developer's mental model of the application. That's why I think I have never seen this.

[maniero]

Invariant is a contract focused on types, states. Perhaps you are looking for Dependent Types, which is hard, and not that useful in most cases. See #339.

[bondsbw]

For compile-time, #413 aims to constrain the ranges of valid values.

[theunrepentantgeek]

We can already achieve everything proposed here within the existing type system.

For example, I've worked on a system that dealt with time series data - we were moving to representing an unvalidated time series id as a string but a validated one as a TimeSeriesId.

For complex validation scenarios, the Proposal Design Pattern is a really good solution that I've used multiple times.
(Disclaimer: That's a link to my own blog because the original article proposing the pattern isn't online,)

[gulshan]

I am not actually proposing guaranteed compile time data validation. It's more like an abstract framework for validation built into language, which compiler can then use to help/suggest the developer to avoid errors. Even this can totally be off the language, but into the standard library, which complier will be using. Similar to what language/compiler will be doing for nullability.

[CyrusNajmabadi]

It's more like an abstract framework for validation built into language, which compiler can then use to help/suggest the developer to avoid errors.

Isn't that just 'analyzers'?

[CyrusNajmabadi]

A data type being able to indicate it can be or should be validated.

How about: [ICanHazValidation]?

A method can indicate it requires validated data for some parameters.

How about: void Foo([INeedzValidation] Bar bar)

A member method or property can indicate that it can only be called on valid objects.

How about: [OnlyAllowedWhenValid] void Foo() { ... }

?

You can express this all with attributes, then use an analyzer to encode any and all rules around those attributes you want.

[gulshan]

All of what you have said is true. I have already said-

Even this can totally be off the language, but into the standard library

3rd party and 1st party analyzers are quite different things for the ecosystem.

[aluanhaddad]

@gulshan

If same data is valid in some context in invalid in another, this language integrated approach will encourage to put them them into two separate type, may be one encapsulating/inheriting another. Which will keep the validation context explicit.

Union types could accomplish this but in a more general way, assuming of course that pattern matching becomes a generally useful language feature.