220 35355 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: ref qualifiers for the standard library (again) Date: Mon, 13 Nov 2017 10:25:17 -0800 (PST) Lines: 188 Approved: news@gmane.org Message-ID: References: <3f41db92-4c4a-400e-8981-456aaab8af07@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4722_486267311.1510597517428" X-Trace: blaine.gmane.org 1510597517 742 195.159.176.226 (13 Nov 2017 18:25:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 18:25:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDWHU7IAKGQEXVVRLKQ@isocpp.org Mon Nov 13 19:25:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEJPz-0008J3-RP for gclcip-std-proposals@m.gmane.org; Mon, 13 Nov 2017 19:25:12 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id l201sf7343121vkd.14 for ; Mon, 13 Nov 2017 10:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=IgJUiqGNo7BD8g6kYQpVbC1LN4zVQr6uD0BRav2Mk4c=; b=Nwf21FFdYNUyuLWtQEsEysoTECKcn/IDxlzWenIzJLmdm2PS+gZshQR2CwL+46mukO 5WxJ51+5gxosTa5yrDDeGZW5Pmhwk/dEqHw0VJwBUATwlcez6erKqwvQrQsXZ37QzXzG 40+LA0UMeTV2giEJ9tWiqg3uaGjVYetJ22PXQGKWSZTmpROINq7uYmln9QCN4Zayv5XV 0z1SAge/r6nsYJ3m2vX3LTJ/hzEwHvQwmLluyQRjqMKcumvREXtI+sEq9AxJZZy5+GOO wmk0cw7vzCC/6KCunqzX5+VkPZIToARv7tC2VLuIIPa8lx2d08wBUJQnYQBuUSP3DcOe ODfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=IgJUiqGNo7BD8g6kYQpVbC1LN4zVQr6uD0BRav2Mk4c=; b=WThQTLxuF0fYcsqutRBEZw+MBYqqh62IJTYbtoEXYkEeLcwPE3bv7rrnCjFeJ3NUia UVg3I/GkCUNGfs+4HKgprS3ZcYhSMSwZRM2WpOk4VVaKfFfCPyie4XzG0Zpi6QLqZyex VKCv/GGWbMOkSLI/86jeem8bIQFROl6AcHRgbgTTXlP6lw4M3eBf4RFbftXBkWc6wsbd 3wJ76/l+DGdKZwjR25ugbyzJrGNAE3mnQX9gJm6S+5B5XQaKGkFy7z6brnI6uh/TQZFo 81GICbfMp1sNeGlVP037SvVYBFi2P8DUHx7KEi28yFYNRIDrXhHssf5q5wlAkA+NrT31 R98A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=IgJUiqGNo7BD8g6kYQpVbC1LN4zVQr6uD0BRav2Mk4c=; b=c/LOavhg2Xf2SykkGrn0SQgnw9KdV/FOjDIjZgGJIm2OL3dXdPb7Un/FgRFyc5wCJT b14XZcsYJGVdzvDEBWLaR2aCkG2YJG0tQnygZmXMooz2nvUQ6CJeVu6BmwNDyjD7F6Rh ORiRGEyIulPbkcPITL1HGNUBENG3sjJFeLh19Obt/GGS75QSdHn87FhgwGHGn7vhiAT2 AlmcOhCeAhqAZPjMIL1Uqpw8UAVRHoeZpmUXDuf16KsbXwQlu+QyJXq2Y7R8TtCHgvbQ f1h3eZoS8qKKd0a3qKxriZ7t9TxvsFvS2UsSMLWfMEQIoe4Akm9Pi2hCqpMN4FwQUyJC PeVQ== X-Gm-Message-State: AJaThX6io8gAtemFOp1H35J++KQsniCoeEyEkAMYvIbuYaHbjF7WaNfv 2Re60N4BAQNwCyCWw1lwGScoMg== X-Google-Smtp-Source: ABhQp+QgH8JmomiJu2tSSgYpjlgvWRhCi76BzOz/hMY+LpqTykq5lztCkkEcR4xch0I7WQO9kNRBsA== X-Received: by 10.176.9.233 with SMTP id e41mr8429353uah.39.1510597519175; Mon, 13 Nov 2017 10:25:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.77.90 with SMTP id k26ls9068020uag.3.gmail; Mon, 13 Nov 2017 10:25:18 -0800 (PST) X-Received: by 10.31.201.198 with SMTP id z189mr1507033vkf.0.1510597517832; Mon, 13 Nov 2017 10:25:17 -0800 (PST) In-Reply-To: <3f41db92-4c4a-400e-8981-456aaab8af07@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:35355 Archived-At: ------=_Part_4722_486267311.1510597517428 Content-Type: multipart/alternative; boundary="----=_Part_4723_1961309150.1510597517428" ------=_Part_4723_1961309150.1510597517428 Content-Type: text/plain; charset="UTF-8" On Monday, November 13, 2017 at 12:42:41 PM UTC-5, Nicolas Lesser wrote: > > I propose to add some ref qualifiers to functions in the standard library, > just like N2819 did in 2009, but for even more > functions. The LWG decided against that paper, and I can't find out why. > The advantage here is that the compiler will error out when trying to call > a function on an object of the wrong value category. This can prevent > subtle bugs from creeping it (due to invalidation) and operations which do > nothing (because the temporary for example gets destructed immediately). > Here are the main types of functions that I want to see with a ref > qualifier: > > P.S: I know that I'm generalizing a bit, and as mentioned in N2819, there > are some classes for which those should no apply, but for most of them, > they do (just ignore those types for a moment). > > 1) & for assignments operators > Those should be obvious. It makes no sense whatsoever to assign a value to > a temporary (like a std::vector) > > #include > > std::vector foo() { return {}; } > > int main() { > foo() = {1, 2}; // what?? > } > > gcc and clang don't generate any warnings on one of the highest warning > levels possible (https://godbolt.org/g/dSXyDJ), even though this code > basically does nothing. > > 2) & for strings (and views) and other containers > > There was a recent question on SO on them ( > https://stackoverflow.com/questions/47261061/stdstring-view-on-temporary-string-catch-by-asan). > The problem there is that std::string has a conversion operator to a > std::string_view, and if the std::string is a temporary, then the returned > std::string_view is invalid soon after. The same thing can happen for c_str > and data, but more obvious. From the SO question: > > #include > #include > #include > > std::string foo() { > return "test"; > } > > int main() { > std::string_view bar = foo(); // bar is pointed to destructed string > std::cout << bar << std::endl; > } > > If the conversion operator would have been marked with a &, this would not > have happened. > And neither would this: void some_func(std::string_view view); some_func(foo()); Yet this is perfectly valid. C++ has no good solution to this problem. You're either going to forbid legitimate code, or allow broken code. We do not have any mechanism at present that allows us to determine when such things are being used legitimately and when they are not. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3e093a8-05e2-4047-9079-c8356d7f12df%40isocpp.org. ------=_Part_4723_1961309150.1510597517428 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, November 13, 2017 at 12:42:41 PM UTC-5,= Nicolas Lesser wrote:
I propose to add some ref qualifiers to functions in the standard = library, just like=C2=A0N2819=C2=A0did in 2009, but for even more functions. The LWG = decided against that paper, and I can't find out why. The advantage her= e is that the compiler will error out when trying to call a function on an = object of the wrong value category. This can prevent subtle bugs from creep= ing it (due to invalidation) and operations which do nothing (because the t= emporary for example gets destructed immediately). Here are the main types = of functions that I want to see with a ref qualifier:

P.= S: I know that I'm generalizing a bit, and as mentioned in N2819, there= are some classes for which those should no apply, but for most of them, th= ey do (just ignore those types for a moment).

1) &= amp; for assignments operators
Those should be obvious. It makes = no sense whatsoever to assign a value to a temporary (like a std::vector)

#include <vector>

st= d::vector<int> foo() { return {}; }

int main= () {
=C2=A0 =C2=A0 foo() =3D {1, 2}; // what??
}
gcc and clang don't generate any warnings on one of the hig= hest warning levels possible (https://godbolt.org/g/dSXyDJ), e= ven though this code basically does nothing.=C2=A0

2) & for strings (and views) and other containers

=
There was a recent question on SO on them (https://stackoverflow.com/questions/47261061= /stdstring-view-on-temporary-string-catch-by-asan). The probl= em there is that std::string has a conversion operator to a std::string_vie= w, and if the std::string is a temporary, then the returned std::string_vie= w is invalid soon after. The same thing can happen for c_str and data, but = more obvious. From the SO question:

#include <s= tring>
#include <string_view>
#include <ios= tream>

std::string foo() {
=C2=A0 =C2= =A0 return "test";
}

int main(= ) {
=C2=A0 =C2=A0 std::string_view bar =3D foo(); // bar is pointed to d= estructed string
=C2=A0 =C2=A0 std::cout << bar << st= d::endl;
}

If the conversion operator wo= uld have been marked with a &, this would not have happened.

And neither would this:

void<= /span> some_func<= /span>(std::string_view view);

some_func(foo());

Yet this is perfectly valid.

C++ has no = good solution to this problem. You're either going to forbid legitimate= code, or allow broken code. We do not have any mechanism at present that a= llows us to determine when such things are being used legitimately and when= they are not.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/c3e093a8-05e2-4047-9079-c8356d7f12df= %40isocpp.org.
------=_Part_4723_1961309150.1510597517428-- ------=_Part_4722_486267311.1510597517428-- .