• Jacob Carlborg (17/17) Sep 13 2013 I just hit a problem in my serialization library, Orange, being
• Brian Schott (4/20) Sep 13 2013 Funny. I just ran into that with msgpack-d in my project... So
• Jacob Carlborg (6/8) Sep 13 2013 I guess __traits(identifier, Foo.tupleof[0]) is more reliable than
• Kapps (9/25) Sep 13 2013 Aye, I had my own code break from this change as well (though it

Jacob Carlborg <doob me.com> writes:

I just hit a problem in my serialization library, Orange, being 
integrated as std.serialization. The format of .stringof changed in git 
HEAD. Now, the question is should the format of .stringof be defined and 
reliable or not defined at all? Either way, this should be clearly 
stated in the documentation, which it's currently not.

Below is what's changed. It's managed to stay unchanged for the last 6-7 
years.

Before the change:

struct Foo
{
     int a;
}

static assert(Foo.tupleof[0].stringof == "(Foo).a");

After the change:

static assert(Foo.tupleof[0].stringof == "a");

-- 
/Jacob Carlborg

"Brian Schott" <briancschott gmail.com> writes:

On Friday, 13 September 2013 at 07:06:27 UTC, Jacob Carlborg
wrote:
 I just hit a problem in my serialization library, Orange, being 
 integrated as std.serialization. The format of .stringof 
 changed in git HEAD. Now, the question is should the format of 
 .stringof be defined and reliable or not defined at all? Either 
 way, this should be clearly stated in the documentation, which 
 it's currently not.

 Below is what's changed. It's managed to stay unchanged for the 
 last 6-7 years.

 Before the change:

 struct Foo
 {
     int a;
 }

 static assert(Foo.tupleof[0].stringof == "(Foo).a");

 After the change:

 static assert(Foo.tupleof[0].stringof == "a");

Funny. I just ran into that with msgpack-d in my project... So
that's two libraries broken.

Jacob Carlborg <doob me.com> writes:

On 2013-09-13 09:11, Brian Schott wrote:

 Funny. I just ran into that with msgpack-d in my project... So
 that's two libraries broken.

I guess __traits(identifier, Foo.tupleof[0]) is more reliable than 
.strinfof. But it would be nice to once and for all get an official 
agreement on this issue.

-- 
/Jacob Carlborg

"Kapps" <opantm2+spam gmail.com> writes:

On Friday, 13 September 2013 at 07:06:27 UTC, Jacob Carlborg 
wrote:
 I just hit a problem in my serialization library, Orange, being 
 integrated as std.serialization. The format of .stringof 
 changed in git HEAD. Now, the question is should the format of 
 .stringof be defined and reliable or not defined at all? Either 
 way, this should be clearly stated in the documentation, which 
 it's currently not.

 Below is what's changed. It's managed to stay unchanged for the 
 last 6-7 years.

 Before the change:

 struct Foo
 {
     int a;
 }

 static assert(Foo.tupleof[0].stringof == "(Foo).a");

 After the change:

 static assert(Foo.tupleof[0].stringof == "a");

Aye, I had my own code break from this change as well (though it 
was a very easy fix in my case). I really prefer the new format 
however. Including the type made reading people's code very 
confusing with the random T.tupleof[T.stringof + 3 .. $] if you 
didn't understand the exact format. That being said, this is 
something that's commonly enough used that it should be defined 
whether or not the format could be relied upon.