Private unstructured types and type reuse

In 1972, three popular computer scientists wrote the book Structural Programming, where they mentioned private unstructured types:

All structured data in the last study should be constructed from unstructured components belonging to primitives or unstructured types. Some of these unstructured types (for example, real numbers and integers) can be taken as given in the programming language or the hardware of the computer. Although these primitive types are theoretically appropriate for all cases, there are strong practical reasons to help the programmer designate his own unstructured types in order to clarify his intentions about the potential limits of the variable values ​​and interpret each such value; and to allow the subsequent design of an effective presentation.

(...) This type is called enumeration, and we recommend standard notation for the type name and the type name association with each of its alternative values.
`
type suit = (club, diamond, heart, spade);
(...)
type year = 1900 ... 1960;
type coordinate = 0 ... 1023;
`

(...) We, therefore, introduce the rule where a ... b denotes the range of values ​​between a and b inclusive. This is known as a subrange / subgroup (approx. Subrange) of the type to which a and b belong, (...)

( in English )
Ole-Johan Dahl, Edsger W. Dijkstra, CAR Hoare, Structured Programming, APIC Studies in Data Processing, No. 8, 1972, p.97

Some languages ​​actually support subgroup types, such as Ada and Delphi . However, modern popular languages ​​such as Java and C # do not directly support unstructured private subgroup types.

In addition to this, there is a huge misunderstanding between the type declaration and its real value. For example, in .NET Array takes Integer as an index in the range [-2 ^ 31, 2 ^ 31], so we declare support for the numbers -1, -2, ... as index values. At the same time, only non-negative numbers are valid, i.e. [0, 2 ^ 31]. For honest and clear code, Array [NonnegativeInteger] should be used.

Moreover, often used structured and unstructured types are not limited to numbers. Today, email is often represented as a String type:

function void SendEmail(String email, String emailBody){ ... } 

although in fact we mean

 function void SendEmail(EmailAddress email, String emailBody){ ... } 

Assuming that every object of the EmailAddress class / structure is always true, we no longer have to check the string each time with the IsEmail () helper or the DataAnnotations attribute (in .NET). It can have a function EmailAddress TryConvert (String email) for easy conversion from a string.

Other typical places for obvious improvements:

• Names
  Checking the name of the String type for the name and surname among the entire program with the same restrictions, possibly with no more than 256 special characters and at least one character, can be replaced with what the programmer really means: class / structure Name .
  
• class Description with general rules for contact messages, order comments, feedback messages, etc.
  
• Measures: degrees, coordinates, weight, etc.
  
• date and time
  Numbers up to 2147483648 (2 ^ 31) for the year, month, day, hour, and minute do not seem convenient in real use, and many systems will eventually throw out an error using large numbers for these types.
  
• Money
  There are no banknotes of minus $ 100, but there may be a notion of debt of $ 100.
  

With the help of Design by Contracts, most checks can be made at compile time. For compatibility with other systems, private types must be built from primitive and simple types, like Integer and String , and also be convertible from these types.