• Jacob Carlborg (14/14) Dec 15 2011 I know that this might be too late but wouldn't it be possible to defer
• Don (2/14) Dec 16 2011 Why not just change your D1 code to use alias instead of typedef?
• bearophile (4/5) Dec 16 2011 Walter introduced typedef in D1 for a purpose: it introduces stronger st...
• Trass3r (2/7) Dec 16 2011 Which we will do in D2 too if we don't finish the library based typedef ...
• Jacob Carlborg (5/22) Dec 16 2011 In this case it's a serialization library and I would like to support

Jacob Carlborg <doob me.com> writes:

I know that this might be too late but wouldn't it be possible to defer 
the error message about typedef to later in the compile phase. Making it 
possible to put a typedef in a version statement, something like:

version (D_Version2) {}
else {
     typedef int foo;
}

This would allow to both support D1 and D2 in a library without the need 
for string mixins. Obviously the compiler still knows about typedef 
since it can give a proper error message about it so I was hoping it 
wouldn't have to be as the case with the new D2 keywords which do 
require a string mixin if you're supporting both D1 and D2.

-- 
/Jacob Carlborg

Don <nospam nospam.com> writes:

On 16.12.2011 08:41, Jacob Carlborg wrote:
 I know that this might be too late but wouldn't it be possible to defer
 the error message about typedef to later in the compile phase. Making it
 possible to put a typedef in a version statement, something like:

 version (D_Version2) {}
 else {
 typedef int foo;
 }

 This would allow to both support D1 and D2 in a library without the need
 for string mixins. Obviously the compiler still knows about typedef
 since it can give a proper error message about it so I was hoping it
 wouldn't have to be as the case with the new D2 keywords which do
 require a string mixin if you're supporting both D1 and D2.

Why not just change your D1 code to use alias instead of typedef?

bearophile <bearophileHUGS lycos.com> writes:

Don:

 Why not just change your D1 code to use alias instead of typedef?

Walter introduced typedef in D1 for a purpose: it introduces stronger static
typing. So if in future you will want to modify/refactor your D1 code, typedefs
will help you avoid introducing some bugs. If you replace them with alias, you
lose something.

Bye,
bearophile

Trass3r <un known.com> writes:

 Why not just change your D1 code to use alias instead of typedef?

 Walter introduced typedef in D1 for a purpose: it introduces stronger  
 static typing. So if in future you will want to modify/refactor your D1  
 code, typedefs will help you avoid introducing some bugs. If you replace  
 them with alias, you lose something.

Which we will do in D2 too if we don't finish the library based typedef  
soon.

Jacob Carlborg <doob me.com> writes:

On 2011-12-16 13:31, Don wrote:
 On 16.12.2011 08:41, Jacob Carlborg wrote:
 I know that this might be too late but wouldn't it be possible to defer
 the error message about typedef to later in the compile phase. Making it
 possible to put a typedef in a version statement, something like:

 version (D_Version2) {}
 else {
 typedef int foo;
 }

 This would allow to both support D1 and D2 in a library without the need
 for string mixins. Obviously the compiler still knows about typedef
 since it can give a proper error message about it so I was hoping it
 wouldn't have to be as the case with the new D2 keywords which do
 require a string mixin if you're supporting both D1 and D2.

 Why not just change your D1 code to use alias instead of typedef?

In this case it's a serialization library and I would like to support 
all available types.

-- 
/Jacob Carlborg