DMD 0.166 release

[Bruno Medeiros]

Derek Parnell wrote:
> On Thu, 31 Aug 2006 20:32:01 -0700, Walter Bright wrote:
> 
>> Derek Parnell wrote:
>>> Damn! I didn't know that. What's the rationale for such a seemingly
>>> arbitrary restriction?
>> No virtual functions for structs!
> 
> Ok, that meant nothing to me until I translated it from the OO jargon. Here
> is my attempt at converting Walter's answer into human speech ;-)
> 
> The 'format' function examines each parameter supplied to it in order to
> convert it into some form of string. When it comes to a class object, it
> casts the object instance to 'Object' and then calls Object.toString(),
> which through the magic of 'virtual functions' actually gets around to
> calling the parameter's own toString() method if it exists. 'virtual
> functions' is the mechanism in which derived classes can have their methods
> called via reference to their parent class. Now structs are not derived
> from anything and thus there cannot be a generic toString() method in a
> struct parent. So the 'format' function doesn't know which struct
> toString() to call and it throws the exception instead. 
> 
> I guess that when D eventually gets runtime reflection we will be able to
> improve 'format' to check if the struct parameter passed to it has a
> toString method and thus call it.
> 

Another alternative is a syntax using the concatenation operator:
   writefln("through a voltage of" ~ v);
This can be done already with overloading of opCat_r and opCat, but it's 
way less than ideal since it has to be done for every new type. Or D 
could be changed so that '~' itself would try to call toString() if it 
existed.

Yet another alternative is for any type that has a toString() member 
function to be implicitly castable to string (aka "char[]"). Then 
writefln would be declared as a typesafe variadic function of (string[] 
strs ...). It would also be necessary for implicit casting to work with 
typesafe variadic function calls, which seems it doesn't (I wonder if 
that's by design?). And it would be necessary for primitives to have 
toString "member functions" (it's unusual, but I don't see any problem 
with that. Primitives already have properties for example). Usage would be:
   writeln("X is ", 1.2345 );
Note we would lose the formatting capabilities(no "f"). To do formatting 
we could do for example:
   writeln("X is ", (1.2345).toString("%1.2d") );

Just some wacky ideas. :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D