Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue 15941 -- rbtree no longer supports classes #4353

Merged
merged 1 commit into from
May 27, 2016

Conversation

schveiguy
Copy link
Member

Simple -- if type doesn't support formatting the range, then don't define toString. This means it defaults to Object.toString in those cases, but this isn't really a problem.

There are likely better ways to do this, but this fixes the regression now.
Need to see how docs get generated to find out if I did that part right.

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
15941 [REG v2.069] rbtree no longer supports classes

@schveiguy
Copy link
Member Author

ping @MartinNowak, can we get this in 2.071.1?

sink(")");
static if(is(typeof((){FormatSpec!(char) fmt; formatValue((const(char)[]) {}, ConstRange.init, fmt);})))
{
void toString(scope void delegate(const(char)[]) sink, FormatSpec!char fmt) const {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the problem with that delegate signature is that toString can not be @safe because you can't call put(const(char)[]) @System delegate.

One solution would be to make it trusted, by that is bad as well. I think at some point we have to make a choice what is the lesser evil. Disallow @safe toString by default or be @trusted and hope.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's part of a template so all that is inferred

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh you mean the delegate? Yeah, one possibility would be to template that parameter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but does the toString of Object pick that template up?

another idea would be an overload of Object.toString taking a @safe delegate and a @System delegate

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toString of Object doesn't have this form I don't think. But in any case we can save this for another time, the important thing is that this is fixing a regression where you can't use classes as element types

@schveiguy
Copy link
Member Author

Interesting difference between ddox and ddoc here. I left the docs outside static if, and it seems to be fine for ddoc, but ddox has removed the toString documentation. ping @s-ludwig

@schveiguy
Copy link
Member Author

I changed the docs so hopefully they work with ddox.

@schveiguy
Copy link
Member Author

hopefully they work with ddox

Nope, still didn't help. Not sure what to do...

@s-ludwig
Copy link
Member

This is an issue related to DMD's JSON outuput. Related issue: dlang/ddox#86

I think at some point we'll switch to the libdparse backend for generating the documentation, though, in which case this will be fixed.

@schveiguy
Copy link
Member Author

@s-ludwig OK, thanks for letting me know. I will undo that version(StdDdoc) machinery, if it's technically unnecessary.

@schveiguy
Copy link
Member Author

Fixed up the docs.

@JackStouffer
Copy link
Member

I find it a little funny that my first contribution to Phobos lead to a serious regression.

LGTM

element type can be formatted. Otherwise, the default toString from
Object is used.
*/
static if(is(typeof((){FormatSpec!(char) fmt; formatValue((const(char)[]) {}, ConstRange.init, fmt);})))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No nicer trait available?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a PITA to do. At first, I did if(is(typeof(formatValue((const(char)[]){}, ConstRange.init, FormatSpec!(char).init)), but formatValue takes the format spec by ref.

Perhaps there is a nicer trait. I'm not sure.

@MartinNowak MartinNowak merged commit dbc30e6 into dlang:stable May 27, 2016
@schveiguy
Copy link
Member Author

@JackStouffer not your fault: 1) I find it funnier that we had no test of classes as an element type, 2) the Object default functions need to go.

@schveiguy schveiguy deleted the fix15941 branch May 27, 2016 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants