At the moment, various integer types are being used in igraph
, ranging from int
to long int
to igraph_integer_t
. This post describes a proposal to clean up the integer types, and in particular, support 64bit integers properly. This is a quite disruptive breaking change with respect to previous major releases. We therefore want to do this only once, so we want to make sure that we are doing this right. We therefore also solicit feedback from users about this proposal. We plan to do this for release 0.10.
Basic data types
We intend to have four basic (i.e. atomic) data types:

igraph_real_t
. This will always be adouble
, i.e. a 64bit floating point number. 
igraph_integer_t
. This will be an integer type that by default is 64bit on 64bit systems and 32bit on 32bit systems. It will be configurable to be a 32bit integer type, even on 64bit systems, in order to support the R interface, which unfortunately does not support 64bit integers. 
igraph_bool_t
. This datatype will represent a boolean. Typically, we can store this in achar
data type (8bit). In order to support the R interface, this type is configurable to use a 32bit integer instead. 
igraph_complex_t
. This datatype will represent a complex number, consisting of a real part and a complex part, both of which are represented asigraph_real_t
.
In public headers, no other basic data types are allowed. All data types used in igraph
should be defined on the basis of these four basic data types. Internally, it may be necessary to sometimes use other types, for example to interface with external libraries, or to support specific implementations of random number generators. This usage should be limited to what is strictly necessary.
In particular, this means that there should be (nearly) no int
or long int
being used, but only igraph_integer_t
. Similarly, (almost) no float
or double
should be used, only igraph_real_t
.
Arraylike data structures
At the moment there are various arraylike data structures that are defined on several basic data types. In particular, these are vector
, matrix
, array3
, dqueue
, heap
,and stack
. We intend to limit these data structures to the four basic data types that are introduced above. For example, for vector
, we would only support the following types:

igraph_vector_real_t
, defined as a vector ofigraph_real_t
elements. 
igraph_vector_integer_t
, defined as a vector ofigraph_integer_t
elements. 
igraph_vector_bool_t
, defined as a vector ofigraph_bool_t
elements. 
igraph_vector_complex_t
, defined as a vector ofigraph_complex_t
elements.
In addition, we will have a “default” type:

igraph_vector_t
will be identical to anigraph_vector_real_t
.
This default is consistent with the current implementation.
For the other data structures, we would similarly support only the indicated four basic data types, and make the “default” be identical to the data type defined on an igraph_real_t
.
Similarly to the basic data types, in public headers, no other arraylike data structures are allowed. All data types used in igraph
should be defined on the basic of these four basic data types. Internally, it may be necessary to sometimes use other types, for example to interface with external libraries. This usage should be limited to what is strictly necessary. Although we may develop some helper data types for this specific purpose, these data types will be strictly private, and only limited to these specific purposes.
In particular, this means that we will remove igraph_vector_char_t
, igraph_vector_long_t
, igraph_vector_int_t
and igraph_vector_float_t
from the library, with of course first a deprecation of these types. Similarly, these types would also be remove for the other arraylike data structures.
Errors
At the moment, most functions return an int
for signalling an error condition. We will change this so that functions that return an error will return an igraph_error_t
instead, which will be typedef’d to an int
. This does not change the return data type of the functions, but it will clarify the semantics of the function definitions. It also distinguishes it from other functions that do return an actual integer, such as igraph_vcount
, and not an error code.
Configurability
The R interface only supports double
and int
values. Hence, in order to keep supporting the R interface, we need to make the igraph_integer_t
and the igraph_bool_t
configurable to both be an int
. Since any arraylike data structures are defined on the basis of these basic data types, they should automatically change along with it. This should be strictly limited to the R interface only, and should not be used in other settings.
Graph representation
At the moment, the graph is represented using igraph_vector_t
, i.e. using double
s. At some point, we will change this to work with the integer type, i.e. igraph_vector_integer_t
. This will break much of the existing code, because the interaction with the graph is usually based on handling igraph_vector_t
.
Previous discussions
This topic is further discussed in various places, starting at Put integer types into order · Issue #1450 · igraph/igraph · GitHub, with some follow up discussions in Fix integer types by vtraag · Pull Request #1626 · igraph/igraph · GitHub, including some more technical details.