On Thu, Jul 9, 2020 at 11:07 AM Filippo Casarin via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I haven't explained what it does in the first mail so i will explain now.
This proposal introduces more ways to overload a function.

What is `void f(int x, int y) {}` supposed to do differently from `void f(int x; int y) {}` or `void f(int x: int y) {}`?
In this case for the machine there is no difference other than the name mangling.

So they're mangled differently?  Does that mean that
int f(int x; int y);
int f(int x, int y);
forms a valid overload set?

Given
int g(int x; int y);
auto pg = &g;
what is the type of `pg`? Is it `int (*)(int;int)`?  Is that type convertible to `int (*)(int,int)` — why or why not?


Given the code
void foo(int a=1000696967, int b=1000696969);
In c++20 there is no way to call `foo` specifying a value for `b` but not for `a`

With this proposal you will be allowed to do it in the following way
void foo(int a=1000696967; int b=1000696969);
foo(; 7); // calling foo with default valute for `a` and `b` = 7

That doesn't follow from your original proposal at all!
Vice versa, we could discard everything from your original proposal and simply propose instead that
    int h(int x=1, int y=2);
    ... h(,42) ...
should call `h(1,42)`.
This has already been proposed and rejected, AFAIK (maybe someone else can dig up the proposal).
Vice versa, it has certainly been cited as a reason to reject Python-style trailing commas: Python permits
    int f(int x, int y);
    ... f(1,2,) ...
with the same meaning as
    ... f(1,2) ...
https://godbolt.org/z/4Whnax
and this would be very nice to have in C++ as well — but people have said "We should hold off on that, because maybe trailing-comma should mean 'argument omitted,' " exactly as you are now proposing.

Besides, consider that we could get that feature in several different ways. The obvious one would be
    int h(int x=1, int y=2);
    ... h(default, 42) ...
This might be considered better anyway (certainly I consider it better) because it reduces the possibility of the classic DO10I typo:
    h(,42);  // calls h(1, 42)
    h(.42);  // calls h(0, 2)

Many of my complaints here are informed by the inference that you're trying to find new and crazier ways to shoehorn default function arguments into the language, when default function arguments are already a huge source of confusion and bugs in real code:
https://quuxplusone.github.io/blog/2020/04/18/default-function-arguments-are-the-devil/


In c++20 you can't have multiple parameters packs in a function, the only solution I know is from the std::pair constructor but it's too long to call
std::pair<std::complex<double>, std::string> p6(  // from https://en.cppreference.com/w/cpp/utility/pair/pair
                    std::piecewise_construct,
                    std::forward_as_tuple(0.123, 7.7),
                    std::forward_as_tuple(10, 'a'));

 The new syntax would be
std::pair<std::complex<double>, std::string> p6(0.123, 7.7; 10, 'a');

Interesting. So you would make `...` parameter packs work only with comma-separated arguments?
    template<class... Ts> void p(Ts... ts) {}
    p(1,2,3);  // OK
    p(1;2;3);  // invalid
    p(1:2:3);  // invalid
Would you provide a way to use packs with : and ; arguments? Why or why not?
Consider
    void q(auto... ts; int i=1) {}
    q(42);  // does this call q(42;1) or q(;42)? why?
    void r(auto... ts; auto... us) {}
    r(42);  // does this call r(42;) or r(;42) or is it ambiguous or is it invalid? why?


The colon has been included just for the slice because other possibilities didn't look as good
arr[i:j] // slicing an array
arr[i, j] // indexing a matrix
arr[i; j] // does not mean anything to me

Here's a possibility that looks even better:
    arr.slice(i, j)  // slicing an array (C++98)
    m.at(i, j)  // indexing a matrix (C++98)
    m[i, j]  // indexing a matrix (C++23)

–Arthur