apenn-msft

+1 to what @MikeGitb has said the pre-C++17 syntax for enum init from braces {} is ideal for pure-"[enumeration](https://en.wikipedia.org/wiki/Enumeration#:~:text=An%20enumeration%20is%20a%20complete%2C%20ordered%20listing%20of,of%20all%20of%20the%20elements%20of%20a%20set.)" users (i.e. using an enum as a list of predefined enumerators)...

I agree with this; there should not be mention of 'project' or other names for arbitrary structure we impose on our code, but note that @gdr-at-ms in #1596 wanted to...

I'm ok with standardese where the alternative means using terms partial to an implementation; we do already mention "implementation defined" in the guidelines, e.g.: > and be aware of constructs...

@gdr-at-ms "include search path" is ambiguous; 19.2.2 and 19.2.3 both refer to a "search" being conducted for both and "" forms. I think the term could work if we qualify...

It's partially correct, except: > there's still only one path; as you noted, there are _two_ paths: > for the two lookups this is why the term "include search path"...

Not MSVC, but Apple does: https://stackoverflow.com/questions/3429031/header-search-paths-vs-user-header-search-paths-in-xcode that's a concrete example although I was more referring to the abstract standard language, which mentions both "" and as performing a "search" (and...

To summarize the current state of the various comments: apenn-msft: I'm approved with comments; if we can slip in some of the copy-edits @Quuxplusone brought up, that would be great,...

> kind of tautological in context: here's how it is used: > from a locally relative file, versus a standard library header or **a header from the header search path**...