On 4/16/20 7:18 PM, John McFarlane via Std-Proposals wrote:
>
> (The first is its design — nit: I don't think this is a "problem";
> I think this is "your preferred solution to the second problem."
> Me personally, I definitely want it to be a member function, for
> ergonomics; and I would want it to work on any random-access
> range, even `deque`
> <https://en.cppreference.com/w/cpp/container/deque/at>. I would
> also want some exploration of the existing std::map facility:
> should m.at <http://m.at>(idx) mean (idx < m.size() ? m[idx] :
> throw out_of_range()), and if not, why not? Generic programming
> requires extracting the commonalities between different possible
> parameter types, and I don't think that work is entirely done yet.)
>
>
> It sounds like you want the (UFC?) syntax but that's different to
> justifying membership. There are good reasons to prefer free functions
> to member functions. Numerous sources (such as the CCG
> <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c4-make-a-function-a-member-only-if-it-needs-direct-access-to-the-representation-of-a-class>
> and H&A's C++ Coding Standards) do a good job of explaining them. That
> many users like their 'dot' style is not sufficient reason to
> perpetuate the design error that led to, e.g., string's bloated API.

Devil advocate for a second here: as a user of std::span, why should I
care whether at() needs access to the object representation or not?

Does span::front() need inner access, or can it just be *begin() and
thus should not be a member?
Does span::operator[] need access, or can it just be *(begin() + N) and
thus should be not a member (ok, it needs to be because language
limitations. still...)?
Does span::begin() need inner access, or can it just be
std::addressof(span[0]) and thus should not be a member?
Etc.

Unified function call isn't exactly "coming soon", so, as a user, this
just feels that C++ is setting up arbitrary roadblocks deciding what has
to be a member and what hasn't.


>
> The second is the contention that comes from C++'s
> exceptions burden. One of the biggest problems (and biggest
> benefits) of at() is that it throws an exception on
> out-of-bounds. This is cute and nice and wonderful, save for
> that in C++ this means bringing in a dependency on using
> "throw", and throwing a standard exception. All standard
> exceptions defined in the standard library -- out_of_range(),
> for example -- have a constructor that takes a std::string,
> because the string view technology wasn't there yet.
>
> This WOULD cost every person using the span header enormously
>
>
This is also hardly a user's problem or "fault" for merely asking for
the Standard Library to be consistent with itself (e.g. by providing
at() on all classes that have operator[]). Provide it, then find a
global solution (that will benefit everyone) to the problem of the
transitive inclusion of <string>. Why crippling my code?

</devil's advocate>

Thanks,

-- 
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts