Date: Wed, 22 Jul 2020 13:43:02 +0100
1) deducing this *does* piggyback on the existing free-function mechanisms
for deduction. That's practically the entire point - we don't have to
change any template wording at all.
2) UFCS is a non-starter - unless you introduce explicit opt-in syntax for
it. We have UNPROPOSED ideas on that front:
struct Foo {
friend void func(this Foo&) {} // friend + explicit this parameter =
callable both ways
};
but they require that one first introduces the explicit designation anyway.
It's also not guaranteed that EWG will agree that this is even desirable.
We did think about it, though, and tried to make sure it's possible to go
there in the future if that's where the language wants to go.
G
On Wed, Jul 22, 2020 at 1:00 PM Eyal Rozenberg <eyalroz_at_[hidden]>
wrote:
> Gasper, would this proposal be obviated/simplified if we had uniform
> call syntax? i.e. wouldn't it make more sense to piggy-back onto the
> existing standalone function mechanisms for deduction?
>
> Eyal
>
> On 18/07/2020 10:42, Gašper Ažman via Std-Proposals wrote:
> > Already in the pipeline - deducing this.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0847r4.html
> > <
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155471017&sdata=bChBVJ%2BMAihDzWY7Bmh3NdBBOMk54bQ4SjuESo0wySo%3D&reserved=0>
>
> >
> >
> > It's well on track for acceptance.
> >
> > On Sat, Jul 18, 2020, 06:29 David Ledger via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > Hello Everyone,
> >
> > Duplicate function bodies seem to exist everywhere in C++ codebases.
> > This attempts to reduce duplicate code by allowing deduction of
> > const for a function. Allowing a const and non-const function to
> > have the same function body but call the appropriate const or
> > non-const functions.
> >
> > What I'm talking about it that everyone writes:
> >
> > iterator begin();
> > iterator begin() const;
> >
> > T & operator[](size_t i);
> > T const & operator[](size_t i) const;
> >
> > Same for operator[] and function at, and begin, end, front, back
> etc...
> >
> > For the const and non-const versions of the function, often the body
> > of these functions is identical, all that changes is the return type
> > and the selected overloads in the function body. I don't really see
> > the benefit for this and want to improve this.
> >
> > So I want to propose the following:
> >
> > const(auto),
> > const(boolean expr)
> >
> > noexcept(auto), we already have noexcept(boolean expr)
> >
> > This would let me write:
> >
> > iterator begin() const(auto);
> >
> > The problem this introduces is how is the return type determined
> > here, well to do that we would need the bool available for the user:
> >
> > abbreviated syntax:
> > auto begin() const(is_const) -> iterator<is_const>;
> >
> > or,
> >
> > template syntax:
> > template <bool is_const>
> > auto begin() const(is_const) -> iterator<is_const>;
> >
> > or,
> >
> > template syntax with return using conditional_t
> > auto begin() const(is_const) -> conditional_t<is_const,
> > citerator, iterator>;
> >
> > There are additional benefits here:
> > - Keep function logic in one place, not many.
> > - Use template parameters of a class to fully const or not-const all
> > functions in a class.
> > - Reduce the maintenance cost of std library code by halving (in
> > some cases) the number of overloads.
> >
> > As I see it, what needs to be solved:
> > - Member function pointers, how to get an exact one?
> >
> > I'm happy to write up a proposal for this to submit.
> > Anyone have and feedback before I write it up?
> >
> > Regards,
> > David Ledger
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden] <mailto:
> Std-Proposals_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155481012&sdata=J06Nj5UH%2B2nl%2BO0lJ%2F7tUGQuhHINDtKoOXtbdyUdgOo%3D&reserved=0
> >
> >
> > *This email is from an external mail server, be judicious when opening
> > attachments or links *
> >
> >
>
for deduction. That's practically the entire point - we don't have to
change any template wording at all.
2) UFCS is a non-starter - unless you introduce explicit opt-in syntax for
it. We have UNPROPOSED ideas on that front:
struct Foo {
friend void func(this Foo&) {} // friend + explicit this parameter =
callable both ways
};
but they require that one first introduces the explicit designation anyway.
It's also not guaranteed that EWG will agree that this is even desirable.
We did think about it, though, and tried to make sure it's possible to go
there in the future if that's where the language wants to go.
G
On Wed, Jul 22, 2020 at 1:00 PM Eyal Rozenberg <eyalroz_at_[hidden]>
wrote:
> Gasper, would this proposal be obviated/simplified if we had uniform
> call syntax? i.e. wouldn't it make more sense to piggy-back onto the
> existing standalone function mechanisms for deduction?
>
> Eyal
>
> On 18/07/2020 10:42, Gašper Ažman via Std-Proposals wrote:
> > Already in the pipeline - deducing this.
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0847r4.html
> > <
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155471017&sdata=bChBVJ%2BMAihDzWY7Bmh3NdBBOMk54bQ4SjuESo0wySo%3D&reserved=0>
>
> >
> >
> > It's well on track for acceptance.
> >
> > On Sat, Jul 18, 2020, 06:29 David Ledger via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > Hello Everyone,
> >
> > Duplicate function bodies seem to exist everywhere in C++ codebases.
> > This attempts to reduce duplicate code by allowing deduction of
> > const for a function. Allowing a const and non-const function to
> > have the same function body but call the appropriate const or
> > non-const functions.
> >
> > What I'm talking about it that everyone writes:
> >
> > iterator begin();
> > iterator begin() const;
> >
> > T & operator[](size_t i);
> > T const & operator[](size_t i) const;
> >
> > Same for operator[] and function at, and begin, end, front, back
> etc...
> >
> > For the const and non-const versions of the function, often the body
> > of these functions is identical, all that changes is the return type
> > and the selected overloads in the function body. I don't really see
> > the benefit for this and want to improve this.
> >
> > So I want to propose the following:
> >
> > const(auto),
> > const(boolean expr)
> >
> > noexcept(auto), we already have noexcept(boolean expr)
> >
> > This would let me write:
> >
> > iterator begin() const(auto);
> >
> > The problem this introduces is how is the return type determined
> > here, well to do that we would need the bool available for the user:
> >
> > abbreviated syntax:
> > auto begin() const(is_const) -> iterator<is_const>;
> >
> > or,
> >
> > template syntax:
> > template <bool is_const>
> > auto begin() const(is_const) -> iterator<is_const>;
> >
> > or,
> >
> > template syntax with return using conditional_t
> > auto begin() const(is_const) -> conditional_t<is_const,
> > citerator, iterator>;
> >
> > There are additional benefits here:
> > - Keep function logic in one place, not many.
> > - Use template parameters of a class to fully const or not-const all
> > functions in a class.
> > - Reduce the maintenance cost of std library code by halving (in
> > some cases) the number of overloads.
> >
> > As I see it, what needs to be solved:
> > - Member function pointers, how to get an exact one?
> >
> > I'm happy to write up a proposal for this to submit.
> > Anyone have and feedback before I write it up?
> >
> > Regards,
> > David Ledger
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden] <mailto:
> Std-Proposals_at_[hidden]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155481012&sdata=J06Nj5UH%2B2nl%2BO0lJ%2F7tUGQuhHINDtKoOXtbdyUdgOo%3D&reserved=0
> >
> >
> > *This email is from an external mail server, be judicious when opening
> > attachments or links *
> >
> >
>
Received on 2020-07-22 07:46:34