Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm going to try my best to frame this question in a way that doesn't result in a language war or list, because I think there could be a good, technical answer to this question.

Different languages support type aliases to varying degrees. C# allows type aliases to be declared at the beginning of each code file, and they're valid only throughout that file. Languages like ML/Haskell use type aliases probably as much as they use type definitions. C/C++ are sort of a Wild West, with typedef and #define often being used seemingly interchangeably to alias types.

The upsides of type aliasing don't invoke too much dispute:

  • It makes it convenient to define composite types that are described naturally by the language, e.g. type Coordinate = float * float or type String = [Char].
  • Long names can be shortened: using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute.
  • In languages like ML or Haskell, where function parameters often don't have names, type aliases provide a semblance of self-documentation.

The downside is a bit more iffy: aliases can proliferate, making it difficult to read and understand code or to learn a platform. The Win32 API is a good example, with its DWORD = int and its HINSTANCE = HANDLE = void* and its LPHANDLE = HANDLE FAR* and such. In all of these cases it hardly makes any sense to distinguish between a HANDLE and a void pointer or a DWORD and an integer etc..

Setting aside the philosophical debate of whether a king should give complete freedom to their subjects and let them be responsible for themselves or whether they should have all of their questionable actions intervened, could there be a happy medium that would allow the benefits of type aliasing while mitigating the risk of its abuse?

As an example, the issue of long names can be solved by good autocomplete features. Visual Studio 2010 for instance will alllow you to type DSBA in order to refer Intellisense to System.Diagnostics.DebuggerStepBoundaryAttribute. Could there be other features that would provide the other benefits of type aliasing more safely?

share|improve this question
Intellisense or not, System.Diagnostics.DebuggerStepBoundaryAttribute is much less readable in code than DSBA, especially when used often. – zvrba Jun 23 '11 at 7:44
@zvrba: actually, DebuggerStepBoundaryAttribute is much more readable than DSBA. In the first case, you know what does it mean. In the second one, you have no idea. Now imagine you use twenty different aliases like this in code. Would anyone have enough courage to try to read and understand your code? – MainMa Jun 23 '11 at 8:12

Two features come to my mind:

Portability. In languages like C, where datatypes like int are platform specific, an alias like DWORD makes it easier to ensure you are really using a 32bit signed integer everywhere, when this is the requirement for your program, even when you port the program to a plattform where int is e.g. 16bit unsigned and therefore DWORD has to be an alias for signed long.

Abstraction. In your program, you might use a lot of integer and floating point numbers for different purposes. By creating aliases like SPEED, HEIGHT, TEMPERATURE, it's relatively easy to change one of those e.g. from float to double and leave the others as they are.

share|improve this answer
That doesn't answer the question though... – Rei Miyasaka Jun 16 '11 at 22:58
@Rei, you are right that ammoQ did not answer the question but really commented on it. Nevertheless, P.SE does not allow formatted or long comments... I think he doesn't deserve a downvote: his comment is on topic and a good one. – Ando Jun 23 '11 at 6:42
@Andrea it doesn't seem to be the result of having read the question in its entirety; aside from the note on portability (which is just another item to put in list of upsides), it's just a restatement. – Rei Miyasaka Jun 23 '11 at 22:57

I agree with Andrea you need encapsulation, however I disagree that this needs to be expensive.

I think the Happy medium would be type safe typedefs, probably allowing explicit conversion between the real type and the typedef, but preventing implict conversion.

i.e. the main problem I see with typedefs in alot of languages is they do not actually introduce a new type but simply an alias, while this is useful, it is not as useful as a new type which is like the old type but with a new name. And composition or inheritance are too heavy if you only want to ensure you don't mix a couple of variables.

share|improve this answer
I could not agree more, I would really like to see this kind of "limited" polymorphism. If type Name = String, then a String cannot be passed to a function expected a Name, but the reverse is possible. – Matthieu M. Jun 23 '11 at 17:07

I think type aliases give the lazy programmer (very) cheap encapsulation. So maybe the alternative could be just to use proper (expensive) encapsulation.

There is also the argument that the former is also much more optimized for the machine / language in use than the latter, though.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.