You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's no reason to make an exposition-only member public; it doesn't really make sense to provide users with access to an unspecified name. LWG has avoided public exposition-only members in the past, but some have managed to sneak into the subject subclauses (split_view's member find-next, and chunk_view's find-next and find-prev). It's not clear to me if this was a deliberate choice by LWG, or simply an oversight that should be corrected in the working draft.
The text was updated successfully, but these errors were encountered:
CaseyCarter
changed the title
[range.split.view,range.chunk.by.view] Declare public exposition-only member functions
[range.split.view,range.chunk.by.view] public exposition-only member functions?
Oct 5, 2022
Should we also specify in [objects.within.classes] that "Whenever an exposition only member is referred in another class defined in the standard library, the member is considered accessible." alongwith making all of them private?
There's no reason to make an exposition-only member public; it doesn't really make sense to provide users with access to an unspecified name. LWG has avoided public exposition-only members in the past, but some have managed to sneak into the subject subclauses (
split_view
's memberfind-next
, andchunk_view
'sfind-next
andfind-prev
). It's not clear to me if this was a deliberate choice by LWG, or simply an oversight that should be corrected in the working draft.The text was updated successfully, but these errors were encountered: