Alias types

[bvdberg]

Currently C2 allows aliasing a type like: type Name (implemenation type), eg

type SrcLoc u32;

The main goal for aliasing is to allow developers to differentiate different meanings for the same base type. For example a u32 can be an name_idx or a src_loc. At the moment, the alias has a canonical type of the base type. So the alias behaves exactly as the implementation type, it only looks different in the source code. Let's call this weak aliasing. The issue with weak aliases is that the analyser can't find issues like:

fn void test1(SrcLoc loc, Name name) { .. }

test1(loc, name);
test1(name, loc);  // <-- arguments swapped, but analyser just sees 2x u32, so approves

My proposal is to make the types stricter, let's call this strong aliasing. Strong aliases only allows implicit conversion to/from the implementation type type.

type SrcLoc u32;
type Name u32;

Name name = 10; // ok
SrcLoc loc = 20; // ok
loc = name; // error
test1(name, loc); // error

my proposal:

• only allow the implementation type to be a basic type (u32, u8, etc).
• Don't allow pointers/arrays as implementation type. There is no need for this and it would unnecessarily complicate everything
• all alias types are strong. Only conversion to/from the base type is allowed implicitly.
• So strong alias types are their own canonical type.

As a note, Enum types are very similar to strong aliases for the implementation type.

[chqrlie]

I am strongly favorable to this, yet with a grain of salt:

• are you proposing a new keyword alias for distinct types? Why use a new syntax over the current syntax type SrcLoc u32;?
• for consistency, type should produce distinct types whereas alias would produce interchangeable types (weak aliases). But I don't think we need a keyword for this, just an weak attribute would suffice.
• the restriction on the the implementation type seems unneeded and counter productive: it goes against information hiding. If conversion to and from the implementation type is OK, this would allow specialized types to use functions defined on their implementation type, eg:

  type NameIdx u32;    // a name index into a string pool, used by `const char* Pool.idx2name(Pool *p, NameIdx idx)`
  type AstIdx NameIdx; // an index into the astPool, can be passed to `const char* Pool.idx2name(Pool *p, NameIdx idx)`
  type AuxIdx NameIdx; // an index into the auxPool, can be passed to `const char* Pool.idx2name(Pool *p, NameIdx idx)`
  

• along the same lines, why disallow pointer types? With implicit conversions to and from the implementation type, type String const char*; would work the same and can be passed to string functions.
• what about operators: do these types transparently convert to their base type in expressions? Can I define PoundForce and Newton as strict aliases on double so they don't get accidentally mixed in function calls but still use them in computations? Remember the Mars Surveyor Orbiter :)

Overall, I don't think we need a new concept, just more restricted semantics on simple type definitions, possibly relaxed with an attribute @(weak). The same might apply to enum types too, where a weak enum would behave like C enums.

[bvdberg]

Ahh my mistake. I was thinking about alias and typing type. No i'm not proposing another syntax, just using the existing one.
Sorry for the confusion. I have corrected the text above.

I always dislike it very much when someone typedefs a pointer type in C, like typedef Bar* Barp.
Then it looks like passing by value, but actually a pointer is passed. It also brings in extra complexity that doesn't bring anything.

You could of course do PoundForce and Newton, as doubles are base types as well. They would be different types.

type PoundForce f64;
type Newton f64;
PoundForce pf = ..;
Newton newton = ..;
pf = newton; // error
newton = pf; // error
f64 a = pf; // ok
pf = a; // ok

So the only changes from the current system would be:

• make it a distinct type
• update the conversion checker to allow conversion to/from the implemenation type
• disallow non-basic implementation types.