Dear Mario,

On Wed, Apr 15, 2020 at 12:48 PM Mario Charest <stayprivate_at_[hidden]>
wrote:

> - The compile time argument: Modules are designed to fixed this? More
> importantly std::span uses std::array which does have at(), so stdexcept
> and string will end up being included anyway. Seems like the price is
> already paid for?
>

     A better-done implementation can separate this cost by making the
constructor that uses the std::array a template (it has to be a template
for the size anyways) and use a forward declaration to detect is_array;
this means you don't have to pay for including <array>.

     Modules do help compile times, though. So maybe that makes it better.

- The free function at() is not part of C++20. One has to create a "non
> standard" way of dealing with this while most containers do provide such
> functionality. In my case I'm doing maintenance at the moment, want to
> replace some pointers stuff with span (using GSL span in C++17). But now I
> need to create a new function, put it in our libs, testcases, release that,
> train user
>

     Yep, it's always a crapshoot to have to polyfill / patch the standard
for things you want.


> - Abseil own implementation of span provides the function. GSL does not
> though. Might actually be simpler to customizes GSL's <span> and add at()
> to it than create an at()/template that will always feels like an
> unatural thing.
>

     Consistency can be fun, but as mentioned later..


> - It's there for most containers, bite the bullet (if there is a bullet
> in the first place) and wait for std2 to rework the design.
>

     I'd love to bite the bullet and not put it in at all at some point in
my life, when I'm not fixing other things. :D


> - Do we really need yet another non orthogonal thingy.
> - Readability
> - data[10][10]
> - data.at(10).at(10)
> - at(at(data,10),10) // I felt a bunch of my neurones explode on that
> one. And I did not put in the namespaces. That would could mean including
> <range> ? I'm guessing <range> might be as costly as <string>.
>

    This is on track (but not in yet) to be data[10, 10] for C++23; removal
of comma in operator[] was received favorable and I believe the Committee
is in favor of deprecating, removing, and fixing all in one cycle, thank
god. We can do the same for at() and make it variadic: at(data, 10, 10). A
little more template boilerplate to do but it's do-able, I guess.

Re: modules and noexceptions mode for Embedded vendors. I'm not sure: we
barely have full modules implementations for desktop targets. I'm wondering
how modes and things will be handled with modules, especially since macros
aren't exactly the best way to do it anymore unless it's all defined
up-front on the command line...