Date: Sun, 19 Jul 2020 03:21:42 +0000
Thanks for that, I hadn't seen that one.
I don't think that solution makes sufficient effort to decrease verbosity.
It introduces another new syntax and special case whereas the const suggestion I made here is similar to our current noexcept(true) and to a lesser extent decltype(auto).
The openstd proposal does reduce duplication. But, it also results in more verbose code, requiring self when accessing to members. This this is an unfamiliar way of referring to members.
I'd much prefer being able to simply delete my overloads and add a const(auto). Instead of having to re-write the function using self.
Also, default const case has a problem getting a function pointer.
And what is the format of the proposed member function pointer in the openstd. It would look dissimilar to the prototype function definition and I think that's just weird.
The examples also show an excessive use of the std::forward, something I find particularly verbose.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>
Sent: Saturday, July 18, 2020 10:46:22 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Std-Proposals Digest, Vol 16, Issue 23
Send Std-Proposals mailing list submissions to
std-proposals_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
or, via email, send a message with subject or body 'help' to
std-proposals-request_at_[hidden]
You can reach the person managing the list at
std-proposals-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Ptr proposal: looking for feedback (Jefferson Carpenter)
2. Language Feature for Reducing Duplicated Code (David Ledger)
3. Re: Language Feature for Reducing Duplicated Code (Ga?per A?man)
4. Re: Ptr proposal: looking for feedback (Lyberta)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Jul 2020 17:52:22 +0000
From: Jefferson Carpenter <jeffersoncarpenter2_at_[hidden]>
To: Matthew Woehlke <mwoehlke.floss_at_[hidden]>,
std-proposals_at_[hidden]
Subject: Re: [std-proposals] Ptr proposal: looking for feedback
Message-ID: <43efcc47-a753-eda0-0531-dc98f7ff4b2c_at_[hidden]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 7/17/2020 3:22 PM, Matthew Woehlke wrote:
>
> That said... the trade-offs of a non-thread-safe reference counter
> pointer are obvious. What I'm *not* seeing is a significant value in
> being able to release the object in the callee, rather than when the
> callee returns. This seems like a questionable improvement for the added
> complexity.
That's fair. I'm using it myself so that I can refactor my code in ways
that change the ownership semantics, and write classes that can refer to
objects but may or may not own them, without refactoring to alternate
between std::unique_ptr and & as ownership changes, and without the
overhead of an atomic refcount.
I imagine that it could be used in high-performance settings where it's
important to free resources as early as possible during heavy
computation, but a guess is not a use case.
>
> Anyway, it seems that you could accomplish the same thing with a
> non-thread-safe shared_ptr, and your proposal would be much easier to
> understand if you simply presented it as such.
>
That's definitely a good way to present it. I would add that a refcount
is only needed if it's not known statically what the last use of the
resource is. In single-threaded code, that's always the last occurrence
of the lvalue.
------------------------------
Message: 2
Date: Sat, 18 Jul 2020 05:29:17 +0000
From: David Ledger <DavidLedger_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: [std-proposals] Language Feature for Reducing Duplicated Code
Message-ID:
<BL0PR11MB3444C1467E71DE6FF3D812F5FA7D0_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 3
Date: Sat, 18 Jul 2020 08:42:55 +0100
From: Ga?per A?man <gasper.azman_at_[hidden]>
To: std-proposals_at_[hidden]
Cc: David Ledger <DavidLedger_at_[hidden]>
Subject: Re: [std-proposals] Language Feature for Reducing Duplicated
Code
Message-ID:
<CAANG=kU8Dw_netcceAULTohzknLD0J6BHDqx6AxURaP+fzAdDg_at_[hidden]>
Content-Type: text/plain; charset="utf-8"
Already in the pipeline - deducing this.
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=JvN3qoQwyY62xKFqjeP%2F9W9jEyedwL1oKY%2Fx6iL6y8Y%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]> 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]
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
>
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 4
Date: Sat, 18 Jul 2020 15:42:50 +0300
From: Lyberta <lyberta_at_[hidden]>
To: Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Ptr proposal: looking for feedback
Message-ID: <1b215e69-352c-32bc-7b1c-70680c935214_at_[hidden]>
Content-Type: text/plain; charset="utf-8"
Ville Voutilainen via Std-Proposals:
> On Fri, 17 Jul 2020 at 17:40, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>> But if that were actually the only use-case, then we wouldn't need ptr<T> at all! There's already an idiomatic C++ way of doing that:
>> void betterfunc(Foo& f);
>> ... betterfunc(local); ... // no ownership
>> ... betterfunc(*std::make_unique<Foo>(42)); // construct an owning unique_ptr, and then deallocate it afterward
>> If the parameter `Foo& f` were const-qualified, we could even do this:
>> ... betterfunc(Foo(42)); ... // construct a Foo and deallocate it afterward, without even using the heap!
>
> ..but if the parameter of betterfunc is supposed to be nullable, none
> of that nonsense works.
This is exactly why we need std::optional<T&> in the standard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fstd-proposals%2Fattachments%2F20200718%2F707a833d%2Fattachment.sig&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=dd2o4hV7gey8PHJ8OVbj60TxABsz0UyvxkpsZJViWI8%3D&reserved=0>
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
------------------------------
End of Std-Proposals Digest, Vol 16, Issue 23
*********************************************
I don't think that solution makes sufficient effort to decrease verbosity.
It introduces another new syntax and special case whereas the const suggestion I made here is similar to our current noexcept(true) and to a lesser extent decltype(auto).
The openstd proposal does reduce duplication. But, it also results in more verbose code, requiring self when accessing to members. This this is an unfamiliar way of referring to members.
I'd much prefer being able to simply delete my overloads and add a const(auto). Instead of having to re-write the function using self.
Also, default const case has a problem getting a function pointer.
And what is the format of the proposed member function pointer in the openstd. It would look dissimilar to the prototype function definition and I think that's just weird.
The examples also show an excessive use of the std::forward, something I find particularly verbose.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>
Sent: Saturday, July 18, 2020 10:46:22 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Std-Proposals Digest, Vol 16, Issue 23
Send Std-Proposals mailing list submissions to
std-proposals_at_[hidden]
To subscribe or unsubscribe via the World Wide Web, visit
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
or, via email, send a message with subject or body 'help' to
std-proposals-request_at_[hidden]
You can reach the person managing the list at
std-proposals-owner_at_[hidden]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Ptr proposal: looking for feedback (Jefferson Carpenter)
2. Language Feature for Reducing Duplicated Code (David Ledger)
3. Re: Language Feature for Reducing Duplicated Code (Ga?per A?man)
4. Re: Ptr proposal: looking for feedback (Lyberta)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Jul 2020 17:52:22 +0000
From: Jefferson Carpenter <jeffersoncarpenter2_at_[hidden]>
To: Matthew Woehlke <mwoehlke.floss_at_[hidden]>,
std-proposals_at_[hidden]
Subject: Re: [std-proposals] Ptr proposal: looking for feedback
Message-ID: <43efcc47-a753-eda0-0531-dc98f7ff4b2c_at_[hidden]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 7/17/2020 3:22 PM, Matthew Woehlke wrote:
>
> That said... the trade-offs of a non-thread-safe reference counter
> pointer are obvious. What I'm *not* seeing is a significant value in
> being able to release the object in the callee, rather than when the
> callee returns. This seems like a questionable improvement for the added
> complexity.
That's fair. I'm using it myself so that I can refactor my code in ways
that change the ownership semantics, and write classes that can refer to
objects but may or may not own them, without refactoring to alternate
between std::unique_ptr and & as ownership changes, and without the
overhead of an atomic refcount.
I imagine that it could be used in high-performance settings where it's
important to free resources as early as possible during heavy
computation, but a guess is not a use case.
>
> Anyway, it seems that you could accomplish the same thing with a
> non-thread-safe shared_ptr, and your proposal would be much easier to
> understand if you simply presented it as such.
>
That's definitely a good way to present it. I would add that a refcount
is only needed if it's not known statically what the last use of the
resource is. In single-threaded code, that's always the last occurrence
of the lvalue.
------------------------------
Message: 2
Date: Sat, 18 Jul 2020 05:29:17 +0000
From: David Ledger <DavidLedger_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: [std-proposals] Language Feature for Reducing Duplicated Code
Message-ID:
<BL0PR11MB3444C1467E71DE6FF3D812F5FA7D0_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 3
Date: Sat, 18 Jul 2020 08:42:55 +0100
From: Ga?per A?man <gasper.azman_at_[hidden]>
To: std-proposals_at_[hidden]
Cc: David Ledger <DavidLedger_at_[hidden]>
Subject: Re: [std-proposals] Language Feature for Reducing Duplicated
Code
Message-ID:
<CAANG=kU8Dw_netcceAULTohzknLD0J6BHDqx6AxURaP+fzAdDg_at_[hidden]>
Content-Type: text/plain; charset="utf-8"
Already in the pipeline - deducing this.
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=JvN3qoQwyY62xKFqjeP%2F9W9jEyedwL1oKY%2Fx6iL6y8Y%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]> 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]
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
>
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 4
Date: Sat, 18 Jul 2020 15:42:50 +0300
From: Lyberta <lyberta_at_[hidden]>
To: Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Ptr proposal: looking for feedback
Message-ID: <1b215e69-352c-32bc-7b1c-70680c935214_at_[hidden]>
Content-Type: text/plain; charset="utf-8"
Ville Voutilainen via Std-Proposals:
> On Fri, 17 Jul 2020 at 17:40, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>> But if that were actually the only use-case, then we wouldn't need ptr<T> at all! There's already an idiomatic C++ way of doing that:
>> void betterfunc(Foo& f);
>> ... betterfunc(local); ... // no ownership
>> ... betterfunc(*std::make_unique<Foo>(42)); // construct an owning unique_ptr, and then deallocate it afterward
>> If the parameter `Foo& f` were const-qualified, we could even do this:
>> ... betterfunc(Foo(42)); ... // construct a Foo and deallocate it afterward, without even using the heap!
>
> ..but if the parameter of betterfunc is supposed to be nullable, none
> of that nonsense works.
This is exactly why we need std::optional<T&> in the standard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fstd-proposals%2Fattachments%2F20200718%2F707a833d%2Fattachment.sig&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=dd2o4hV7gey8PHJ8OVbj60TxABsz0UyvxkpsZJViWI8%3D&reserved=0>
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7C%7C45e979e3bdca4fdc076008d82b183014%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637306730172261061&sdata=feVewnLRRfsIaTyEemd4sUrSx1pFNg%2FKnhDJJ%2BzYM04%3D&reserved=0
------------------------------
End of Std-Proposals Digest, Vol 16, Issue 23
*********************************************
Received on 2020-07-18 22:25:05