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

add opIn for std.process.environment #4941

Merged
merged 2 commits into from
Feb 21, 2017

Conversation

John-Colvin
Copy link
Contributor

@John-Colvin John-Colvin commented Dec 9, 2016

Useful because:

  • Fewer windows API calls than get
  • Less bookkeeping than get on windows & posix
  • It's syntactically nice.

Why does it not return a string with the variable? Because that would mean it was just an alternative syntax for get and pretty pointless.
Why not do something clever and return a const(string)* in order to fully mimic an AA? Because I don't think there's any way of doing that even close to efficiently.

@John-Colvin
Copy link
Contributor Author

John-Colvin commented Dec 15, 2016

This has been failing tests randomly due to https://issues.dlang.org/show_bug.cgi?id=16352, which is unrelated to the code in this PR.

@John-Colvin
Copy link
Contributor Author

ping anyone? Does this need andralex approval for a new symbol? @CyberShadow or @schveiguy perhaps?

Copy link
Member

@wilzbach wilzbach left a comment

Choose a reason for hiding this comment

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

I don't know much about the Windows API, so I just stick to point out two nits.

// failures
throw new WindowsException(err);
}
else static assert(0);
Copy link
Member

Choose a reason for hiding this comment

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

There should always be a message for assert(0)s

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does phobos even support anything other than posix or windows? I only put these in as sanity checks for future porters.

doSomething(var);
-------------
*/
bool opBinaryRight(string op : "in")(in char[] name) @trusted
Copy link
Member

Choose a reason for hiding this comment

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

Any reason why you don't use string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Consistency with the rest of the environment API.

Copy link
Member

Choose a reason for hiding this comment

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

in char[] is preferable over string when immutability is not required (i.e. we don't save a reference to the string, or a slice of it, past the function's return), because this allows calling the function with const or mutable char arrays.

@wilzbach wilzbach self-assigned this Feb 15, 2017
@wilzbach wilzbach removed their assignment Feb 15, 2017
@wilzbach
Copy link
Member

Does this need andralex approval for a new symbol?

I am not sure - I just tagged it with the motivation of "better be safe than sorry".
(also sorry for the assignment noise - I accidentally hit the wrong button on my phone)

@CyberShadow
Copy link
Member

I remember I asked for opIn_r a while ago and @schveiguy or @kyllingstad convinced me it was unnecessary and a bad idea, but I can't find the discussion, so pinging them.

The diff looks good to me though.

@kyllingstad
Copy link
Member

The reason I didn't add in in the first place was that, as @John-Colvin pointed out, there is no good way to make it return a pointer to the value. I figured having an in operator which behaved differently than for AAs would just break with users' expectations. But the performance argument is a good one; I hadn't thought of that. I have no problem with this change.

Copy link
Member

@kyllingstad kyllingstad left a comment

Choose a reason for hiding this comment

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

My only concern about this was the unconventionality of in returning bool, but it seems there is precedence for this in Phobos already (1, 2). So this looks good to me.

@quickfur
Copy link
Member

ping @andralex

std/process.d Outdated
@@ -3251,16 +3293,20 @@ private:
// New variable
environment["std_process"] = "foo";
assert (environment["std_process"] == "foo");
assert ("std_process" in environment);
Copy link
Member

Choose a reason for hiding this comment

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

BTW (and I realize you're sticking to existing style) I think Phobos style is to treat assert like a function, not a keyword (i.e. no space before ().

Copy link
Member

Choose a reason for hiding this comment

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

yah, no space after assert cc @wilzbach

Copy link
Member

Choose a reason for hiding this comment

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

See #5169 for an enforcement and automatic unification of this assert style ;-)

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

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

thx!

std/process.d Outdated
@@ -3251,16 +3293,20 @@ private:
// New variable
environment["std_process"] = "foo";
assert (environment["std_process"] == "foo");
assert ("std_process" in environment);
Copy link
Member

Choose a reason for hiding this comment

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

yah, no space after assert cc @wilzbach

@wilzbach wilzbach added this to the 2.074.0 milestone Feb 21, 2017
@John-Colvin
Copy link
Contributor Author

Changed all the asserts in the file to the correct format

@wilzbach
Copy link
Member

Changed all the asserts in the file to the correct format

FWIW #5169 does this for entire Phobos in one go, but it doesn't hurt.
(set to auto-merge)

@dlang-bot dlang-bot merged commit 10a149a into dlang:master Feb 21, 2017
@John-Colvin John-Colvin deleted the opIn_environment branch February 21, 2017 11:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants