Skip to content

add opIn for std.process.environment#4941

Merged
dlang-bot merged 2 commits intodlang:masterfrom
John-Colvin:opIn_environment
Feb 21, 2017
Merged

add opIn for std.process.environment#4941
dlang-bot merged 2 commits intodlang:masterfrom
John-Colvin:opIn_environment

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
Contributor

@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.

// GetEnvironmentVariable doesn't specify whether it sets on all
// failures
throw new WindowsException(err);
}
Copy link
Contributor

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.

if (auto var = environment.get("MY_ENV_VAR"))
doSomething(var);
-------------
*/
Copy link
Contributor

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
Contributor

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
Contributor

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
Contributor

@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
// 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
Contributor

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
// 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
Contributor

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