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 *
>
>