Skip to content

std.net.curl: fix for -dip1000 #5052

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.

Sign up for GitHub

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

Closed
WalterBright wants to merge 1 commit into from
Closed

std.net.curl: fix for -dip1000 #5052

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions std/net/curl.d
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2879,7 +2879,7 @@ struct HTTP
/** The headers read from a successful response.
*
*/
@property string[string] responseHeaders()
@property string[string] responseHeaders() return
{
return p.headersIn;
Copy link
Contributor

@JackStouffer JackStouffer Jan 24, 2017

Choose a reason for hiding this comment

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

Technically speaking, isn't this fine because you're returning a reference to GC handled memory rather than a reference to the struct itself?

Copy link
Member

@PetarKirov PetarKirov Jan 26, 2017

Choose a reason for hiding this comment

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

As far as the compiler is concerned, you could have used malloc to create the associative array (even though currently that's far from straightforward). The only thing that it cares about is that you're returning a reference to one of its members. scope and return are orthogonal to @nogc AFAIU.

The strange thing is that it looks like the inferred scope of this is transitive, because you're not returning a reference to a field, but a reference to the object pointed by the field. @WalterBright can you shed some light on this?

Copy link
Contributor

@JackStouffer JackStouffer Jan 26, 2017

Choose a reason for hiding this comment

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

you're not returning a reference to a field, but a reference to the object pointed by the field

Right, that's my issue with this. Because the AA isn't part of the struct and it's GC-ed this is perfectly safe.

Copy link
Member Author

@WalterBright WalterBright Feb 9, 2017

Choose a reason for hiding this comment

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

The root of an associative array is a pointer, and marking with return tells the compiler that the lifetime of that pointer is tied to the lifetime of the struct. The lifetime of a pointer is as long as the pointer exists, which must be a subset of how long the value contained in the pointer is live.

Copy link
Contributor

@JackStouffer JackStouffer May 20, 2017

Choose a reason for hiding this comment

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

But isn't the pointer to the AA not tied to the lifetime of the struct at all? The lifetime of the AA is as long as the GC doesn't collect it, right?

Copy link
Member Author

@WalterBright WalterBright May 21, 2017

Choose a reason for hiding this comment

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

This ties it to the lifetime of the struct.

Copy link
Contributor

@JackStouffer JackStouffer May 21, 2017

Choose a reason for hiding this comment

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

This ties it to the lifetime of the struct.

The point I'm trying to make is that there's no reason that I can see to do that, and I don't understand why we can't let the AA outlive the struct, seeing as how it will always be managed by the GC and therefore doesn't present a safety risk.

Adding return here does not make this code any safer as far as I can tell.

}
Expand All @@ -2900,7 +2900,7 @@ struct HTTP
HTTP status line of last response. One call to perform may
result in several requests because of redirection.
*/
@property StatusLine statusLine()
@property StatusLine statusLine() return
{
return p.status;
}
Expand Down Expand Up @@ -3527,7 +3527,7 @@ struct FTP
}

/// ditto
@property string encoding()
@property string encoding() return
{
return p.encoding;
}
Expand Down