On Mon, 26 Apr 2021 at 00:46, Uecker, Martin via Liaison
<liaison_at_[hidden]> wrote:
> Also: should this paper not be discussed with WG14 as
> well as it possibly constrains the evolution of C?

Sounds like a splendid idea to me. I'm not sure how exactly it
constrains the evolution of C though,
considering that the proposal is limited to user-defined operator[] on
user-defined types only, and C doesn't
have such operators.

For what it's worth, here's what I wrote to EWG earlier today:

Here's a simplified example. We want to remove confusion
between callability and indexability. It's not even a question
of whether we have APIs that take both, it's sufficient that
we have APIs that want to take just the first:

#include <concepts>

void f(std::invocable<int> auto&& x) {
}

struct bad_oink {
    int operator()(int) {return 42;}
    int operator[](int) {return 666;}
};

struct good_oink {
    int operator[](int) {return 666;}
};

int main()
{
    f(bad_oink{});
    // f(good_oink{}); // ill-formed, good!
}

A function that takes a callable will not accept good_oink. There's
no confusion of an indexable type also being callable, and we
have categorically removed a confusion-bug that would need to be debugged.

If we go multi-dimensional today, we can't drive that syntactic
wedge between the two different semantic meanings. With a multi-dimensional
subscript operator, we can.

I don't know about others, but to me, that's sufficient motivation
for adopting this proposal. Sure, fine, we can't do that today and
migrating away from code where that confusion is baked into APIs
and ABIs takes time, but the mere ability to do that once this
proposal is adopted seems like a great improvement to me.

This is not saying anything that the motivation parts in the proposal
aren't saying. Except that this one has a simple example attached
to the explanation. :)

And, as happily often is the case nowadays, you can run it and
play with it:

https://wandbox.org/permlink/A4LvJH1LArcCTmRA