Ada does a great job in this regard. Using some examples in the article:
>> For example, say that you want to represent the number of books ordered. Instead of using an integer for this, define a class called Quantity. It contains an integer, but also ensures that the value is always between 1 and 240
The Ada code to implement this is:
type Quantity is new Integer range 1 .. 240;
>> instead of just using a string, define a class called UserName. It contains a string holding the user name, but also enforces all the domain rules for a valid user name. This can include minimum and maximum lengths, allowed characters etc.
The Ada code to implement this is:
with Ada.Strings.Bounded;
package UserName is new Ada.Strings.Bounded.Generic_Bounded_Length (Max => UserName_Max_Length);
Dynamic predicates or even a string subtype could be used to further refine the UserName definition depending on exactly what restrictions are needed.
While it's not perfect, Ada does make it pretty easy to specify constraints on data types and will complain loudly when the constraints are violated.
It's really not helpful to put examples here that are basically Animal IS Dog level of argumentation. Making toy types like that may help to convince some beginners, but really these features are just unflexible. They work if you're not doing any arithmetic on these values, in which case the type safety is not really needed in the first place. Otherwise (if you're doing arithmetic) they're very much a chore, making code more verbose and in many cases raising complexity to the point where you're starting to introduce enterprisey uber-complicated systems that can easily lead to many thousand lines of boilerplate for solutions that are looking for an actual problem.
And overall, Pascal's type system is NOT so much better. Not strictly better at all, if at all any better. It's a chore to do the simplest things, starting from the mess that is the various types of strings, to a confusing memory management story, continuing with extremely verbose type declaration syntax (which requires to add many additional names), to the mess that is 0-based vs 1-based indexing, and let me not start with the messy object systems that were put on top in Delphi.
If you ask me it's definitely WORSE over all, although for example Delphi has nice aspects to it, especially in the IDE.
Oh yeah, and if Ada was ever adopted by a significant adoption of programmers, then they probably have committed suicide in the meantime.
OCaml, F#, Haskell, Elm, ... (anything with lightweight notation to define sum types [sometimes with only 1 variant], and a module system to limit who can construct them)
TypeScript is surprisingly good at this. It's not popular as a backend language, but shows that your choices aren't limited to pure FP languages and low-level systems programming languages.
Typescript is explicitly bad at this; it is structurally typed, not nominally typed, meaning its effectively useless at enforcing domain guards.
See the same program in flow [1] (nominally typed) and TypeScript [2] (structurally typed).
In the case of flow the type can only be constructed with the class -thus enforcing the guards - whereas in TypeScript I can accidently (or deliberately) bypass all guards by having a class with an equivalent structure.
There are ways to enforce nominal typing in TS [1]
type Brand<K, T> = K & { __brand: T }
type USD = Brand<number, "USD">
type EUR = Brand<number, "EUR">
const usd = 10 as USD;
const eur = 10 as EUR;
function gross(net: USD, tax: USD): USD {
return (net + tax) as USD;
}
gross(usd, usd); // ok
gross(eur, usd); // Type '"EUR"' is not assignable to type '"USD"'.
Thats pretty cool, but it comes with a series of issues:
* It uses an arguably invalid construct "K & { __brand: T }", where K is not an object, is an empty intersection. The fact that typescript allows casting a number to this type is concerning.
* Typescript currently allows "{} as USD" for non-object "K"'s but this will throw up serious issues down the line (obj is not number etc.); this is a likely error after validating JSON for example.
* Similarly typescript will allow you to bypass the guards for primitive types by using the structurally invalid value "{__brand: 'USD'}", or bypass them for object types using a structurally valid form with a "__brand: 'USD'" member. Which is more concerning I don't know.
* The type system now believes you have a member "__brand" that you don't actually have.
* In summary, you cannot enforce the guards through the type system.
That said, this is an interesting hack that, assuming your developers aren't trying to hurt you and you don't use it for primitives, could help get some extra safety in there. However the absurdity of the intersection looms heavily over it, I wouldn't bet on this working in a few years...
Not saying it's the least friction, but Golang can accomplish this pretty easily with interfaces, structs and receivers. In Haskell, you can use phantom types to accomplish this in really elegant way, as is illustrated here: https://wiki.haskell.org/Phantom_type.
And a related question: How far is too far and/or impractical?
I just recently was working on a backend application and was modeling the database entities. The project uses UUIDs as primary keys. Should each entity have its own primary key type? `Location` gets a `LocationId`, User gets a 'UserId', etc, etc, where they're really all just wrappers around UUID?
Honestly, I thought about doing that a bunch of times during the start of the project, but I was pretty sure I'd get some harsh, sideways, glances from the rest of the team.
I've always thought that a language like Idris based on Dependent Types would by far be the best language for this.
The problem is a non-trivial one even for 'simple' things like a person's name. Having a rule that takes in languages, special characters, spaces etc is hard.
> I've always thought that a language like Idris based on Dependent Types would by far be the best language for this.
As someone who loves the idea of dependent types, it seems to me that this is the best theoretical solution, but maybe not the best practical solution. If solving a simple-seeming domain problem involves modelling, not just first-order types, but the whole theory of dependent types, then I think people are going to start looking for escape hatches rather than upgrading their mental models.
Static typing isn't really the only thing here. Strong typing would also be good.
E.g. C has a very weak type system, which is static. There's a lot of implicit conversion going on. Also the expressiveness of the type system is very limited (in C++ also).
OCaml, F#, Haskell and other functional candidates are strongly and statically typed, with very expressive type systems.
Idris with it's dependent types would be ideal and goes even further than the above.
In embedded most likely ADA and Rust offer strong enough static type systems.
> C has a very weak type system, which is static. There's a lot of implicit conversion going on. Also the expressiveness of the type system is very limited (in C++ also).
It is true that the subset that C++ shares to C has too many implicit conversions, but you can do much better.
For example in C++ you can use enum class to define strongly typed integrals that do not implicitly convert to the basic types.
Agree, strongly typed languages are best suited for this as it usually allows to embed business domain invariants into the type system which can be checked at compile time.
Rust does a great job in that regard and is not too slow.
>> For example, say that you want to represent the number of books ordered. Instead of using an integer for this, define a class called Quantity. It contains an integer, but also ensures that the value is always between 1 and 240
The Ada code to implement this is:
type Quantity is new Integer range 1 .. 240;
>> instead of just using a string, define a class called UserName. It contains a string holding the user name, but also enforces all the domain rules for a valid user name. This can include minimum and maximum lengths, allowed characters etc.
The Ada code to implement this is:
with Ada.Strings.Bounded; package UserName is new Ada.Strings.Bounded.Generic_Bounded_Length (Max => UserName_Max_Length);
Dynamic predicates or even a string subtype could be used to further refine the UserName definition depending on exactly what restrictions are needed.
While it's not perfect, Ada does make it pretty easy to specify constraints on data types and will complain loudly when the constraints are violated.