Am I getting this all right?

[Jason House]

Sean Kelly wrote:
> 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.


When poking around that site, I didn't see anything obviously STL 
related.  I've been known to be bline in the past.


>> * 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.

That's exactly correct... Or at the very least the compiler must allow 
such properties to be added to them.  I did try adding my own toString 
property (just in case there was neat hidden feature like that)


>> * 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?

Sorry, typo in my original post.  What you propose is what I put in the 
code.  Yes, I want to handle concrete types as well.


> 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.

That's what I have to do, but it seems to be against "the D way" of 
embedding contracts and unit tests as closely as possible to the true 
code.  I haven't used ddoc, but I bet the alternate method may yield 
misleading documentation.


> 
>> 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 can totally see that.  But what happens when only opCmp is defined? 
Should the default opEquals use opCmp or do something else?  I was 
assuming it'd use opCmp.  Again, in what I perceive to be the style of 
D, such oops type things should possibly cause a warning.


> 
>> 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.


I'll try that.
My actual code was essentially
T[] bar = new T[size];
for (int i=0; i<size; i++)
   T[i] = new T();

... which I totally expect to work.  (sorry for leaving out the array 
sizing in my original example)