Bug 3007 – .stringof is underdocumented

The short mention of the behavior of .stringof in the Properties section of the spec(s) hardly does it justice. It shows simple use on constant expressions and types, but does not specify the formatting of the resulting strings, nor does it say what .stringof does to other language constructs. There is also a lot of interesting behavior which may or may not be compiler bugs: - x.stringof, where x is a int or float constant variable, gives the string representation of the number it holds in D1, and "x" in D2 - funcType.stringof will give information about the ref/out qualifiers of parameters of a function, despite the resulting string not actually being a legal function type - Struct.tupleof.stringof will give a strange-looking string that includes the names of the fields of the struct, which is not unwelcome, but is formatted in a very odd way: "tuple((Struct).x,(Struct).y)" - Getting the .stringof an address expression (like &name) is formatted oddly, with a space between the & and the name - The output of .stringof changes depending on the compiler revision, breaking code. For instance, Struct.stringof used to insert a spurious space before the name, but this is no longer the case This is not an exhaustive list, and most behavior of stringof is completely undefined. It would currently be very difficult to create another D frontend that supports .stringof since its functionality seems to be closely tied to DMD's internals. Specifying its behavior would also make its use much more portable, especially across compiler revisions.

*** Issue 5404 has been marked as a duplicate of this issue. ***

http://dlang.org/property.html#stringof Fixed now?