220 25467 <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Wed, 6 Apr 2016 09:55:11 -0700 (PDT) Lines: 200 Approved: news@gmane.org Message-ID: <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2136_539717698.1459961711375" X-Trace: ger.gmane.org 1459961720 18038 80.91.229.3 (6 Apr 2016 16:55:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2016 16:55:20 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRB4H6SS4AKGQENVKOE3I@isocpp.org Wed Apr 06 18:55:16 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f71.google.com ([209.85.192.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anqja-0002ZC-PG for gclcip-std-proposals@m.gmane.org; Wed, 06 Apr 2016 18:55:15 +0200 Original-Received: by mail-qg0-f71.google.com with SMTP id g33sf24020780qgf.2 for ; Wed, 06 Apr 2016 09:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=eYYzSro0ZS+k06X86tIJuHnm9FDnC3VwTyA5LmmX2ZA=; b=HC43CTjq15zmjhcw2vOGTjaY16pGFXbD26cPDbC69lwpOcWIQUWMgChjlB3OnRs31g SOapaVO6hwo/aplRRKEvKxyioyUHjoUAz4im8z8bt/sc3HiN/1ytzbhlWQz2sX2BE5ko Uk7iiIZfApE8901wKF5YeAjWyO4A6lKc/e4bk6y7tcdplho1f+Oq/w81WfD9VK159Pff wzz6/ZgP2tNguuJlplsCIJJipKOiHn0RdcRYUAJe/DUeexN7+hSfBmBFzwGdse2GCxUI 5xDGwxhXxbP/Z4fEsd8wdFY0Lo1YCXO82vc6CqFwKu+T23UD342/IT9YQeof/QVzSQyQ JiDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc: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=eYYzSro0ZS+k06X86tIJuHnm9FDnC3VwTyA5LmmX2ZA=; b=WRpFiVLae4iE0QM3CHz+feQRg924fqVR1JLNssvFkU9QrqxRAiF7gOcoDSzEImXgSq zUn6WZ/pbj/7c2kuxtrUKPoRiHJPSYsA6LW/YnY2CrE+bCyXkwWiKM5fhveVdA2h1R+i AGdziK6C7NO741sl5pxfFs7TdjOUKa91jyEFPqnGqp2jKfpJVBtwwuvfexUMJ2IwKOCA z86w4YyTVVRKaLv4xfcl/+KmrgbuG4JAO9eZmNtIi/2KFgyUhCrqYUJbKZQ6Jl4Uh/PD CqZjG+PzqZC+n8195OfsfaIpzQUB+MwRll0goHQlrD5jE6J4fbv3vO5mpsuYjoffDTSA 82gQ== X-Gm-Message-State: AD7BkJLEgyGh74YUZpzeRDOmFtXqIJNpFZr/iY+kWIFxRHXfZkFFmz/k1qGn04ouR4fGxA== X-Received: by 10.31.154.65 with SMTP id c62mr3585877vke.8.1459961713406; Wed, 06 Apr 2016 09:55:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.142.142 with SMTP id q136ls511851iod.72.gmail; Wed, 06 Apr 2016 09:55:12 -0700 (PDT) X-Received: by 10.50.129.97 with SMTP id nv1mr459679igb.7.1459961712345; Wed, 06 Apr 2016 09:55:12 -0700 (PDT) In-Reply-To: X-Original-Sender: isocppgroup@denisbider.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25467 Archived-At: ------=_Part_2136_539717698.1459961711375 Content-Type: multipart/alternative; boundary="----=_Part_2137_128809297.1459961711375" ------=_Part_2137_128809297.1459961711375 Content-Type: text/plain; charset=UTF-8 > The committee can mandate that standard library types all have > relocators added where necessary but it can do no such thing for > user types. However, the committee _does_ want to allow variant > to be used with those same problematic user types. With respect to variant, it is already a major advantage of relocation that it can support: - exception-safe use of variant with non-nullable standard library types - without requiring an existing std::list implementation to be thrown away so it can be nothrow_move_constructible; - exception-safe use of variant with future non-nullable types. Existing problematic non-library types can of course still be supported, if we're willing to lose the strong exception safety guarantee in that case. I'm not sure there is a silver bullet that can avoid that. > With your proposal, it's way too easy to accidentally leave > some object in an undefined state I find this logic highly questionable. By this line of reasoning, we should remove placement new, C-style casts, and manual memory management, so that C++ might become a managed language. C++ involves low-level tools that have to be used correctly. Relocation is one. It is safer than current practice, which is to memcpy objects, which invokes undefined behavior and is horrible for static analysis. Relocation allows objects to be moved, while allowing static analysis tools to reason about the program. The general advantage of relocation is that it supports future use of non-nullable types in C++ at all. If relocation is not implemented, non-nullable types will remain fundamentally incompatible with C++ move semantics, and will have to go the way of the Dodo. Forcing all objects to have null states creates another instance of what has been called the Billion-Dollar Mistake: http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare Except for some reason, we are now doing this with object states. On Wednesday, April 6, 2016 at 10:07:11 AM UTC-6, Sean Middleditch wrote: On Wed, Apr 6, 2016 at 8:48 AM, wrote: > Types with throwing move constructors are prime candidates to have a > relocator, because it solves a problem specific to them. A relocator can be > implemented trivially, without changing the design of a non-nullable type > like the particular std::list implementation. It would not require changing > the fundamental design of the type, which implementing a noexcept move > constructor would require. > > For user types, relocators would be implicitly defined by the compiler, > under much the same terms as a move constructor. > > I'm not seeing a plausible usage case where you would want a type to have a > throwing move constructor, and not implement a relocator. It seems plausible > this combination could be unsupported. Much existing code simply wouldn't support relocation properly until someone went in and wrote the relocator functions. You can't generate correct relocations for all types, e.g. those with non-trivial move constructors that do who-knows-what. Those existing types would become incompatible with variants were variant to rely on relocation. That level of requirements has so far been a show stopper for suggestions to "fix" variant. The committee can mandate that standard library types all have relocators added where necessary but it can do no such thing for user types. However, the committee _does_ want to allow variant to be used with those same problematic user types. I personally find this relocation proposal currently incomplete and in need of a lot more iteration. With your proposal, it's way too easy to accidentally leave some object in an undefined state where the compiler has no idea and is stuck calling the destructor anyway. All it takes is passing an object via pointer to some function and *bam* insta-pain, as the caller has no way to know what the function will do and the function has no way to know what the caller wanted to allow, other than comments and documentation (no compiler support for error checking). Standardizable relocation support in C++ is likely to require more work on value categories and probably some kind of new reference or wrapper type (one that cannot be very easily and accidentally bound to sub-objects or glvalues). -- 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/105d82bc-e1cf-4795-894c-112cd591c3af%40isocpp.org. ------=_Part_2137_128809297.1459961711375 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> The committee can mandate that standard library ty= pes all have
> relocators added where necessary but it can do no such= thing for
> user types. However, the committee _does_ want to allow = variant
> to be used with those same problematic user types.


With respect to variant, it is already a major advantage of= relocation that it can support:

- exception-safe = use of variant with non-nullable standard library types - without requiring= an existing std::list implementation to be thrown away so it can be nothro= w_move_constructible;

- exception-safe use of variant with future n= on-nullable types.


Existing problematic non-library = types can of course still be supported, if we're willing to lose the st= rong exception safety guarantee in that case. I'm not sure there is a s= ilver bullet that can avoid that.


&= gt; With your proposal, it's way too easy to accidentally leave
>= some object in an undefined state

I find this log= ic highly questionable. By this line of reasoning, we should remove placeme= nt new, C-style casts, and manual memory management, so that C++ might beco= me a managed language.

C++ involves low-level tool= s that have to be used correctly. Relocation is one.=C2=A0It is safer than = current practice, which is to memcpy objects, which invokes undefined behav= ior and is horrible for static analysis. Relocation allows objects to be mo= ved, while allowing static analysis tools to reason about the program.


The general=C2=A0advantage of relocation is that i= t supports future use of non-nullable types in C++ at all. If relocation is= not implemented, non-nullable types will remain fundamentally incompatible= with C++ move semantics, and will have to go the way of the Dodo.

Forcing all objects to have null states creates another in= stance of what has been called the Billion-Dollar Mistake:


Except for some reason, we are now doing this with object states.
<= div>

On Wednesday, April 6, 2016 at 10:07:11 AM UTC-6, Se= an Middleditch wrote:
On Wed, Apr 6, 2016 at 8:48 AM,=C2=A0 <eloan...@gmail.com> wrote:
> T= ypes with throwing move constructors are prime candidates to have a
>= ; relocator, because it solves a problem specific to them. A relocator can = be
> implemented trivially, without changing the design of a non-nul= lable type
> like the particular std::list implementation. It would = not require changing
> the fundamental design of the type, which imp= lementing a noexcept move
> constructor would require.
>
= > For user types, relocators would be implicitly defined by the compiler= ,
> under much the same terms as a move constructor.
>
&g= t; I'm not seeing a plausible usage case where you would want a type to= have a
> throwing move constructor, and not implement a relocator. = It seems plausible
> this combination could be unsupported.
Much existing code simply wouldn't support relocation properly until <= br>someone went in and wrote the relocator functions. You can't generat= e
correct relocations for all types, e.g. those with non-trivial move <= br>constructors that do who-knows-what. Those existing types would become <= br>incompatible with variants were variant to rely on relocation. That
= level of requirements has so far been a show stopper for suggestions
to= "fix" variant.

The committee can mandate that standard li= brary types all have
relocators added where necessary but it can do no = such thing for user
types. However, the committee _does_ want to allow = variant to be used
with those same problematic user types.


I= personally find this relocation proposal currently incomplete and in
n= eed of a lot more iteration. With your proposal, it's way too easy to <= br>accidentally leave some object in an undefined state where the
compi= ler has no idea and is stuck calling the destructor anyway. All
it take= s is passing an object via pointer to some function and *bam*
insta-pai= n, as the caller has no way to know what the function will do
and the f= unction has no way to know what the caller wanted to allow,
other than = comments and documentation (no compiler support for error
checking). St= andardizable relocation support in C++ is likely to
require more work o= n value categories and probably some kind of new
reference or wrapper t= ype (one that cannot be very easily and
accidentally bound to sub-objec= ts or glvalues).

--
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/105d82bc-e1cf-4795-894c-112cd591c3af= %40isocpp.org.
------=_Part_2137_128809297.1459961711375-- ------=_Part_2136_539717698.1459961711375-- .