Quick start manual
Data types, variables, and constants
5-25
Structured types
•Each constantList is a constant denoting a value of type ordinalType, or a comma-
delimited list of such constants. No value can be represented more than once in the 
combined constantLists.
•Each variant is a semicolon-delimited list of declarations resembling the fieldList: 
type constructions in the main part of the record type. That is, a variant has the 
form
fieldList
1
: type
1
;
ƒ
fieldList
n
: type
n
;
where each fieldList is a valid identifier or comma-delimited list of identifiers, each 
type denotes a type, and the final semicolon is optional. The types must not be long 
strings, dynamic arrays, variants (that is, Variant types), or interfaces, nor can they 
be structured types that contain long strings, dynamic arrays, variants, or 
interfaces; but they can be pointers to these types.
Records with variant parts are complicated syntactically but deceptively simple 
semantically. The variant part of a record contains several variants which share the 
same space in memory. You can read or write to any field of any variant at any time; 
but if you write to a field in one variant and then to a field in another variant, you may 
be overwriting your own data. The tag, if there is one, functions as an extra field (of 
type ordinalType) in the non-variant part of the record.
Variant parts have two purposes. First, suppose you want to create a record type that 
has fields for different kinds of data, but you know that you will never need to use all 
of the fields in a single record instance. For example,
type
TEmployee = record
FirstName, LastName: string[40];
BirthDate: TDate;
case Salaried: Boolean of
True: (AnnualSalary: Currency);
False: (HourlyWage: Currency);
end;
The idea here is that every employee has either a salary or an hourly wage, but not 
both. So when you create an instance of TEmployee, there is no reason to allocate 
enough memory for both fields. In this case, the only difference between the variants 
is in the field names, but the fields could just as easily have been of different types. 
Consider some more complicated examples:
type
TPerson = record
FirstName, LastName: string[40];
BirthDate: TDate;
case Citizen: Boolean of
True: (Birthplace: string[40]);
False: (Country: string[20];
EntryPort: string[20];
EntryDate, ExitDate: TDate);
end;










