@jwakely , please have a look. Is the proposed change editorial from an LWG perspective?

@jensmaurer: could you please make the commit description more specific (not just "fix" in the opening line, but actually hint at what changed)? Also feel free to add some background from the discussion to the second paragraph, e.g. that this was omitted by accident. It's not just "for consistency", but it's really fixing some accidental omission, if I understand correctly? Then feel free to commit.

@tkoeppe, I'm sorry, but this is in fact just for consistency with string_view. "const" vs. "constexpr" doesn't matter in this particular case (static class member of integral type).

I've slightly amended the commit description to avoid "fix".

Yes, it's for consistency abstractly, but as I understand, this change should have been made by some previous paper, where it was forgotten? That's the kind of background that would be nice to know (if true).

@tkoeppe: No. basic_string is ages old, then came along basic_string_view, which used all the new stuff such as "constexpr". Nobody ever thought about upgrading basic_string to follow stylistically, although presentation consistency between basic_string and basic_string_view would be nice. This pull request does it.

OK, thanks. I thought the reflector discussion suggested that this was an oversight in http://wg21.link/P0980R1, but that might not actually have been true.

Well, that paper did add "constexpr" to basic_string member functions, which is a feature add-on. I'm hard pressed viewing "constexpr" on npos as in-scope of that paper; "constexpr" on a member function is quite different from constexpr on a static variable that was already usable in constant expressions.

Yeah, I was thinking that, too -- this is ultimately really nobody's fault.