I understood, there was no sarcasm there either, I meant simply that it seems a little bit silly to create a programming language to replace c/c++, then make the compiler non-distributable. It kinda defeats the object I would think. I *do* see the gentoo problem there, and with the versioning thing too, thats just downright inconsiderate.Genone wrote:I meant as long as both problems exist it's impossible for us to put it in portage, if one is solved we can do it (not saying we will do it). If we can redistribute it it means we can repackage it so the unversioned tarballs wouldn't be a problem.

if thats not enough...What's not Working
Inline assembler
Gray Area / Known Issues
Don't be surprised if you get internal compiler errors.
Debugging information isn't working completely. Things are a little better with DWARF2. Probably need to add D name demangling support to the debugger.
Templates on Mac OS X. The stock compiler doesn't support one-only linkage. Apple's version does support it, but this release will not work with that. Here is a work-around:
Compile modules with the -fno-emit-templates flag.
Put all needed template instances in a separate module (alias MyTemplate!(MyType) some_random_name;) and compile that normally.
Link.
Yay! It's C++ template madness all over again!
Complex floating point operations may not work the same as DMD.
Integer operations may not have the correct signed/unsigned mode.
Registers are not saved on the stack before garbage collection.
The 80-bit real type is not supported on Mac OS X and is replaced by the 64-bit double type.
Some math functions behave differently due to the 80-bit real issue and not being able to access x86 floating-point hardware. The std.math unit tests will fail because of this.
Some hex floating point literals can crash the strtod() function on Mac OS X! These have been commented out.
In order to prevent nested synchronized statements from deadlocking, pthread recursive mutexes are used. This can cause starvation problems on Linux. I will try the "error-checking" type mutex.
Volatile statements probably don't do the right thing.
Thrown exceptions probably leak memory.
Compiling a file with a hyphen in the file name will fail.
Delegates that refer to nested functions are not valid after the parent function returns.



You don't need GNUstep or Cocoa to write and build Objective-C programs. For example, if you take the code here and comment out the #include <Foundation/Foundation.h>, the program will still work just fine because it doesn't use any Foundation code.I tried to settle with Objective-C , but it lacks standard implementations in compilers, you have to rely on a whole "framework" (e.g. GNUStep).
