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








d-bugmail puremagic.com