C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] This deduction and access control
From: Gašper Ažman (gasper.azman_at_[hidden])
Date: 2020-07-21 06:32:17


Arthur,

I agree it's not separable if we don't require new syntax for it. I'm
saying I don't want the UFCS functionality without new syntax, which makes
it separable, since we won't be redefining what current syntax means later.
That's what I meant. Apologies for not making myself clear.

I agree (and have always) agreed with your entire email.

G

On Tue, Jul 21, 2020 at 12:02 AM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> On Mon, Jul 20, 2020 at 6:08 PM Gašper Ažman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> > On Mon, Jul 20, 2020, 21:53 Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >> pon., 20 lip 2020 o 22:42 Barry Revzin <barry.revzin_at_[hidden]>
> napisał(a):
> >>> If by "both call conventions", you mean to also Y::g(Y{}, 1, 2), then
> yes
> >>> that already is valid as stated in the paper (because they're like
> static member functions)
> >>> in the same way that Y{}.g(1, 2) is valid (because they're like
> non-static member functions).
> >>>
> >>> If what you mean is to allow g(Y{}, 1, 2), then... no.
> >>
> >> That was my point, allow `g(Y{}, 3, 2)`, because what difference is to
> >> the definition of `friend int g(Y const&, int, int);`?
> >> Of course paper do not suggest this, but for me this is a logical
> >> conclusion. As this is op-in we do not have problems like other
> >> solutions had for that functionality.
> >
> > That is separable functionality that we will revisit in a future paper
> with explicit syntax to enable it.
>
> Gašper: That's not separable functionality; it's absolutely integral to
> the proposal, in the sense that it cannot be added later.
> I think Barry is right that WG21 shouldn't *want* to add it later, but
> anyway, if they ship the ability to say Y::g(x, y), they can't later go
> back and *add *the ability to also say `g(x, y)` unqualified.
>
> Under the current proposal (AIUI, which is to say, not well),
>
> namespace N {
> struct S {
> void swap(S& this lhs, S& rhs);
> };
> }
> S a, b;
> a.swap(b); // OK
> S::swap(a, b); // OK
> N::swap(a, b); // Won't compile
> swap(a, b); // Won't compile
> std::ranges::swap(a, b); // Will compile and call std::swap(a, b)
>
> Under the proposal "plus ADL" as Marcin was talking about (AIUI),
>
> a.swap(b); // OK
> S::swap(a, b); // OK but maybe not preferred?
> N::swap(a, b); // Won't compile
> swap(a, b); // *OK*
> std::ranges::swap(a, b); // Will compile *and call S::swap(a, b)*
>
> Whenever you add a thing, you have to get it right on the first try, or
> else design it very carefully for extensibility.
> The default is *never* "oh, we can just add that wrinkle later."
>
> my $.02,
> –Arthur
>



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups