digitalmars.D.bugs - [Issue 3007] New: .stringof is underdocumented
- d-bugmail puremagic.com (40/40) May 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3007
- d-bugmail puremagic.com (11/11) Jan 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3007
http://d.puremagic.com/issues/show_bug.cgi?id=3007 Summary: .stringof is underdocumented Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: spec Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: bugzilla digitalmars.com ReportedBy: jarrett.billingsley gmail.com 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3007 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.alexander.au gmail.co | |m 19:54:13 PST --- *** Issue 5404 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 11 2013