Date: Thu, 19 Dec 2019 14:24:31 -0600
On Thu, Dec 19, 2019 at 1:09 PM Andrew Tomazos via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I think this is a problem worth solving. Its against a C++ design
> principle that built-in references (like const std;:string&) have the
> lifetime extension feature, whereas user-defined reference-like classes
> (like std::string_view) do not. In particular, this is one the arguments
> against migrating from const std::string& to std::string_view.
>
> I encourage you to submit a proposal for C++23:
> https://isocpp.org/std/submit-a-proposal
>
I agree with Andrew that it would be desirable to have string_view and
similar user-defined classes be able to extend lifetime. However, I'm not
sure what the following paragraph by OP meant:
> - An argument to a normal function might be used to construct an
> object that outlives the function, e.g. by being returned. In this
> case, the arguments should be marked view recursively. Technically
> speaking this case probably includes the coroutine-case. Diagnostic
> messages for arguments used to construct view parameters to other
> calls, that are not themselves marked view, should be required.
Can you give an example?
std-proposals_at_[hidden]> wrote:
> I think this is a problem worth solving. Its against a C++ design
> principle that built-in references (like const std;:string&) have the
> lifetime extension feature, whereas user-defined reference-like classes
> (like std::string_view) do not. In particular, this is one the arguments
> against migrating from const std::string& to std::string_view.
>
> I encourage you to submit a proposal for C++23:
> https://isocpp.org/std/submit-a-proposal
>
I agree with Andrew that it would be desirable to have string_view and
similar user-defined classes be able to extend lifetime. However, I'm not
sure what the following paragraph by OP meant:
> - An argument to a normal function might be used to construct an
> object that outlives the function, e.g. by being returned. In this
> case, the arguments should be marked view recursively. Technically
> speaking this case probably includes the coroutine-case. Diagnostic
> messages for arguments used to construct view parameters to other
> calls, that are not themselves marked view, should be required.
Can you give an example?
-- *Brian Bi*
Received on 2019-12-19 14:27:09