Summary: .stringof is underdocumented
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2

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

- 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:
------- You are receiving this mail because: -------

Reply via email to