Personally, I don't like this language at all, neither "in" nor "inside". The expression is not "inside" noexcept. We should use language consistent with the core wording or the grammar.

[except.spec] says "that constant expression is the exception specification of the function type in which the noexcept-specifier appears" (emphasis mine).

So we could just say "the exception specification is equivalent to..."

Or we could define a new element which defines the see below expression, and do away with "the expression inside noexcept is equivalent to" entirely.

Others might not agree though, so don't rewrite everything based on this comment alone.

There are several different changes here, and I'd like to see them separated a bit more.

• There is the question of phrasing for "the expression inside", which applies (in principle) to both noexcept and explicit. This needs a wider audience to decide.
• There are typo-level fixes (logop, colons) that could be applied right away.

@JohelEGP , please post a separate pull request that only contains separate commits for the "logop" fixes and the colon fixes.

We should pick our preferred wording for this construct and apply it uniformly everywhere.

Editorial meeting: Say "the /constant-expression/ of the /noexcept-specifier/ is equivalent to" and see how it feels.

Will these two be enough to gauge how it feels?

For requires see below, we have:

https://timsong-cpp.github.io/cppwp/reverse.iterators

    constexpr pointer   operator->() const requires see below;

constexpr pointer operator->() const
  requires (is_pointer_v<Iterator> ||
            requires (const Iterator i) { i.operator->(); });

https://timsong-cpp.github.io/cppwp/iterators.common

    decltype(auto) operator->() const
      requires see below;

decltype(auto) operator->() const
  requires see below;

The expression in the requires-clause is equivalent to:

indirectly_­readable<const I> &&
(requires(const I& i) { i.operator->(); } ||
 is_reference_v<iter_reference_t<I>> ||
 constructible_­from<iter_value_t<I>, iter_reference_t<I>>)

No Remarks:.

https://timsong-cpp.github.io/cppwp/#ranges

  template<movable Val, class CharT, class Traits = char_traits<CharT>>
    requires see below
  class basic_istream_view;

  template<movable Val, class CharT, class Traits>
    requires default_initializable<Val> &&
             stream-extractable<Val, CharT, Traits>
  class basic_istream_view : public view_interface<basic_istream_view<Val, CharT, Traits>> {

  template<input_range V, size_t N>
    requires see below;
  class elements_view;

  template<input_range V, size_t N>
    requires view<V> && has-tuple-element<range_value_t<V>, N> &&
             has-tuple-element<remove_reference_t<range_reference_t<V>>, N>
  class elements_view : public view_interface<elements_view<V, N>> {

These use exposition-only concepts defined before the class template definition.

https://timsong-cpp.github.io/cppwp/range.iota

    constexpr auto size() const requires see below;

constexpr auto size() const requires see below;

Remarks: The expression in the requires-clause is equivalent to

(same_as<W, Bound> && advanceable<W>) || (integral<W> && integral<Bound>) ||
  sized_sentinel_for<Bound, W>

https://timsong-cpp.github.io/cppwp/range.ref.view

    template<not-same-as<ref_view> T>
      requires see below
    constexpr ref_view(T&& t);

template<not-same-as<ref_view> T>
  requires see below
constexpr ref_view(T&& t);

Remarks: Let FUN denote the exposition-only functions

void FUN(R&);
void FUN(R&&) = delete;

The expression in the requires-clause is equivalent to

convertible_to<T, R&> && requires { FUN(declval<T>()); }

https://timsong-cpp.github.io/cppwp/#time

    template<class Rep1, class Period1, class Rep2, class Period2>
      requires see below
      constexpr auto operator<=>(const duration<Rep1, Period1>& lhs,
                                 const duration<Rep2, Period2>& rhs);

template<class Rep1, class Period1, class Rep2, class Period2>
    requires three_­way_­comparable<typename CT::rep>
  constexpr auto operator<=>(const duration<Rep1, Period1>& lhs,
                             const duration<Rep2, Period2>& rhs);

CT is defined in the subclause of the itemdecl.

Consider how the iota_view case would look like with the resolution of the editorial meeting, if applied for consistency:

constexpr auto size() const requires see below;

-Remarks: The expression in the requires-clause is equivalent to
+Remarks: The _constraint-logical-or-expression_ of the _requires-clause_
+is equivalent to:

(same_as<W, Bound> && advanceable<W>) || (integral<W> && integral<Bound>) ||
  sized_sentinel_for<Bound, W>

Editorial meeting: We've reconsidered. Please try "The exception specification is equivalent to:"

Still gauging how it feels, or should I fix it generally now?

Still gauging how it feels; we don't want to generate a lot of work while we're still unsure.

I'd also find this a nice improvement. Let's leave this for another week or two for feedback (@CaseyCarter, @brycelelbach?), but let's tentatively consider this ready.

Personally I'm happy if @jwakely is happy. I think "The exception specification is equivalent to" is a more understandable/approachable for new C++ proposal authors. I do wonder, though, do we have enough of these to merit their own paragraph type? E.g. "Exception Specification: Equivalent to:"? This would nicely mirror the pattern of "Effects: Equivalent to:".

Thanks! We had talked about a new specification element, too, and were generally sympathetic to that idea. I suggested as a first step to go with this proposed change for now, and if it turns out to come up often enough to warrant a new element, we can consider that as a second step.

There's 22 of these.

E.g. "Exception Specification: Equivalent to:"? This would nicely mirror the pattern of "Effects: Equivalent to:".

I don't think mirroring "Effects: Equivalent to ..." is necessarily desirable. For the Effects: paragraph that has very specific meaning with magic powers (it inherits all the constraints and other properties from the equivalent construct). We don't need that for the exception specification, we're just describing a boolean constant.

OK, let's go with the current version for now, as agreed. I think @jwakely makes a good point, so this might be good enough and we just leave it like this, esp. if only 22 paragraphs would be affected by this anyway.