Am I getting this all right?

[Sean Kelly]

Jason House wrote:
> I'm kind of doing a trial by fire method to learn D and how it works... I'm
> taking an existing open source project and converting it over.  Here's the
> stuff that I've found / questions that I have.
> 
> Thanks in advance for all the thoughtful responses.  I know this is a long
> post!  I've worked through the issues to get working code, but I think my
> issues will be hit by others.
> 
> It seems that DTL and minTL are the two candidates for an STL equivalent in D.
>  Both seem to be out of date.  Since minTL is documented, I chose to use that.
>  I found that the latest dmd (0.176) doesn't compile the latest minTL.  It
> complains that va_arg isn't defined even though it imports std.stdarg.  Adding
> a fully qualified name fixed my usage problem.  Is this really the best option
> that I have for STL equivalent?  Anyone else compiling this stuff and hitting
> problems?

Check DSource (www.dsource.org).  IIRC there is at least one STL 
replacement project there.  Of the above, DTL was created by Matthew 
Wilson, and hasn't been updated in at least a year.  MinTL was created 
by Ben Hinkle, and has been dormant for almost as long.  MinTL is more 
mature however, and should be easier to update.

> I know of no way in d to provide a const qualifier.  It seems like the concept
> purely doesn't exist.  minTL appears to have a workaround where it templates
> itself on a boolean value, and simply doesn't publish certain functions.  When
> will a real const qualifier get added to the language?  It seems really
> strange that a language that adds all kinds of contract programming wouldn't
> use const qualifiers / const types.

This is correct.  In D, 'const' is a storage class, and can not be 
applied to values at runtime (essentially).  D has no run-time const 
behavior largely because the implementations in expisting popular 
languages are undesirable (C++ const, for example) for various reasons, 
and some of the more radical solutions such as const-by-default came up 
too late in the language's development cycle (as I understand it).

> After banging my head on printing stuff for a long time, I've come to a few
> conclusions:
> * The C++ equivalent to std::ostream& operator << (std::ostream &out, const
> type &x) does not exist

It could.  Mango (available on DSource) overloaded these operators for a 
while, but no one used them and I think they may have been removed. 
Mango's "whisper syntax" seems preferable in most cases, though it 
doesn't work for an IOStream concept, while the shift operators do.

> * Custom types use the toString property

Yes, though some of us wish this function were called "toUtf8" to 
improve clarity.  This is an idealistic point however, and not pertinent 
to the discussion.

> * Enums do not (and can not) have a toString property

They don't at the moment.  One could be added, I imagine, but it would 
have to be done in the compiler.

> * I have found no way to determine (in a templated class) if a type is
> printable or not.  static if(is(typeof(T))) comes close, but my very first
> test using ints failed.

"static if(is(typeof(T.toString)))" should tell you whether the function 
is defined, if T is a struct or class, but it sounds like you want to 
test concrete types as well?

> The special unittest member function doesn't get built in with -unittest
> unless the actual class is used in some way (and then one copy of the unittest
> funciton gets run for each type).  I'd really like to see some way for this to
> work.  for example, class foo(T){ ... unittest{ foo!(int) sample; ...} } does
> not run unless other code instantiates foo!(U)

Why not do:

     class C(T) {}
     unittest { /* test C here */ }

Since private data is actually visible at module scope, the above 
approach loses nothing over having unittest within the class definition 
itself.

> In my early efforts at doing operator overloading, I wrote opCmp and then was
> shocked when my unit test showed that == didn't even call opCmp.  It silently
> did something wrong.  This seems like a gotcha built into the language that
> should probably get remedied.

It calls opEquals.  Personally, I prefer this approach as it's not 
uncommon for me to define an ordering scheme that is less strict than I 
want for equality comparisons.

> I couldn't find a way to reinitialize a variable back to a default value...
> For example class foo(T){ T[] bar; void func(){bar[3] = new T();} } won't
> compile.  I'm not too sure why this is the case.

Try:

     T[] bar = new T[size];
     T[0 .. $] = new T();

You still have to resize and assign in separate operations, but the 
above should work.


Sean