Library Typedefs are fundamentally broken

Don via Digitalmars-d digitalmars-d at puremagic.com
Mon Sep 22 02:39:28 PDT 2014


On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei Alexandrescu 
wrote:
> On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
>> On Sun, 21 Sep 2014 08:15:29 -0700
>> Andrei Alexandrescu via Digitalmars-d 
>> <digitalmars-d at puremagic.com>
>> wrote:
>>
>>> alias Int1 = Typedef!(int, "a.Int1");
>>> alias Int2 = Typedef!(int, "b.Int2");
>> ah, now that's cool. module system? wut? screw it, we have 
>> time-proven
>> manual prefixing!
>
> Use __MODULE__. -- Andrei


Yes, but you're advocating a hack. The original premise does seem 
to be correct: library Typedefs are fundamentally broken. The 
semantics of templates does not match what one expects from a 
typedef: ie, declaring a new, unique type.

If you have to pass __MODULE__ in, it's not really a library 
solution. The user code needs to pass in a nasty implementation 
detail in order to get a unique type.

And it does seem to me, that because it isn't possible to do a 
proper library typedef, you've attempted to redefine what a 
Typedef is supposed to do. And sure, it you remove the 
requirement to create a unique type, Typedef isn't broken. But 
then it isn't very useful, either. You can't, for example, use it 
to define the various Windows HANDLEs (HMENU, etc), which was one 
of the most successful use cases for D1's typedef.


Having said that, though, the success of 'alias this' does raise 
some interesting questions about how useful the concept of a 
typedef is. Certainly it's much less useful than when Typedef was 
created.

My feeling is that almost every time when you want to create a 
new type from an existing one, you actually want to restrict the 
operations which can be performed on it. (Eg if you have  typedef 
money = double; then money*money doesn't make much sense). For 
most typedefs I think you're better off with 'alias this'.


More information about the Digitalmars-d mailing list