www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9588] New: format prints "null" for struct functions

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588

           Summary: format prints "null" for struct functions
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



15:07:36 PST ---
import std.string;
import std.stdio;

void main()
{
    struct S { int x; bool empty() { return false; } }
    writeln( format("%s", S()) );
}


 S(0, null)


It shouldn't try to print the function. I think this should also apply to
property functions since e.g. "empty" is typically a property function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 25 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|format prints "null" for    |format prints context
                   |struct functions            |pointer for struct



18:11:48 PST ---


 import std.string;
 import std.stdio;
 
 void main()
 {
     struct S { int x; bool empty() { return false; } }
     writeln( format("%s", S()) );
 }
 

 S(0, null)


 
 It shouldn't try to print the function. I think this should also apply to
 property functions since e.g. "empty" is typically a property function.


Oh wait a minute, I know what this is. It's the hidden context pointer. If you
change the struct to 'static' the null disappears. But I don't think format()
should print that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



Is there a way to tell whether a field is the hidden context pointer? Does it
have a specific name (that isn't compiler-dependent)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588




19:01:50 PST ---


 Is there a way to tell whether a field is the hidden context pointer? Does it
 have a specific name (that isn't compiler-dependent)?


None that I know of, but it appears it's always the last member (at least in
DMD).

When we get the isNested[1] trait pulled we could simply do a test on the
aggregate and just ignore the last field when writing its contents.

[1]: https://github.com/D-Programming-Language/dmd/pull/1362

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588




Hmm. Using __traits(allMembers, S) seems to indicate that the field name is
'this'. Since 'this' is a reserved keyword, that may be safer to check for than
assuming that the compiler will always put it last.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588




20:22:21 PST ---


 Hmm. Using __traits(allMembers, S) seems to indicate that the field name is
 'this'. Since 'this' is a reserved keyword, that may be safer to check for than
 assuming that the compiler will always put it last.


Nice catch.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9588




19:18:48 PST ---


 Hmm. Using __traits(allMembers, S) seems to indicate that the field name is
 'this'. Since 'this' is a reserved keyword, that may be safer to check for than
 assuming that the compiler will always put it last.


This won't work out that easy. The code in format uses .tupleof to get to the
values, but .tupleof and allMembers return different results, for example:

void main()
{
    struct S { int x; this(int) { } }
}

allMembers:
tuple("x", "__ctor", "this")

.tupleof:
tuple(0, S(0).this)

So the indexes won't match. Since my new isNested trait was pulled, and
assuming the context pointer is last, I could do:

immutable tupleLen = val.tupleof.length;
foreach (i, e; val.tupleof)
{
    // skip printing context pointer
    static if (__traits(isNested, T) && i+i == tupleLen) { }
}

It's hard to tell whether this will be safe. 

Another idea is to change how .tupleof works internally (to remove exposing the
context pointer), but this might be a bad idea, serialization might probably
require it as well as other code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 07 2013