typedef

[Tim M]

On Sat, 07 Mar 2009 06:47:40 +1300, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> I tried typedef in two instances, to sadly conclude that it's not useful  
> as a true abstraction mechanism. The good news is that it's very close  
> to being useful.
>
> Ideally, typedef should provide a completely parallel type with the type  
> under the typedef, as if you sat down and wrote it from scratch.  
> Unfortunately, today typedef is just about equivariant with the type it  
> comes from:
>
> void main()
> {
>      typedef int IDType;
>      IDType id = 5;
>      int x = id;
> }
>
> This compiles and runs flag-free. An IDType accepts any int without any  
> fuss, and furthermore an int accepts an IDType no problem. As such,  
> typedef introduces neither a supertype nor a subtype of int.
>
> I believe this behavior is unhelpful as it prevents IDType from being a  
> true abstraction mechanism. What should happen is that only this should  
> compile:
>
> void main()
> {
>      typedef int IDType;
>      auto id = IDType(5);
>      int x = id;
> }
>
> So the literals of type IDType have the form IDType(n). That way it's  
> visible that we want to deal in IDType objects. I think it's ok that the  
> int can be be teased out of an IDType without an explicit conversion.  
> Requiring a cast would be a tad too rigid. So with the new rules in  
> place we defined a sort of subtype of int.
>
> This works even better with classes. Consider exceptions for instance:
>
> typedef Exception MyException;
>
> void main()
> {
>      try
>      {
>          throw new MyException("x");
>      }
>      catch(MyException e) { writeln("a"); }
>      catch (Exception e)  { writeln("b"); }
> }
>
> This code doesn't compile with:
>
> Error: catch at ./test.d(19) hides catch at ./test.d(20)
>
> So to the compiler typedefs are today too much the same as the source  
> type.
>
>
> Andrei

I've never really found typedefs of any use. You say it makes it clearer  
that you are dealing with IDType objects. But they are not objects. If you  
had used objects you could have defined the constuctor to get the syntax  
you are looking for because taking away this syntax:

IDType id = 5;

Should also remove the following syntaxes to keep D simple:

*=
+=
-+
%=

etc..


So you end up with a type that stores int data but cant be used for  
arithmetic. What good would that be keeping in mind that D already has  
enums?