220 2743 article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional references -- take 2 Date: Tue, 5 Feb 2013 17:39:16 -0500 Lines: 145 Approved: news@gmane.org Message-ID: References: <8d57e9e9-e4cc-441c-abeb-e6526531fad5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1360103957 32565 80.91.229.3 (5 Feb 2013 22:39:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Feb 2013 22:39:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIJLFGGRACRUBGRV5ZVC@isocpp.org Tue Feb 05 23:39:38 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f70.google.com ([209.85.128.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U2rAu-0008Ap-K7 for gclcip-std-proposals@m.gmane.org; Tue, 05 Feb 2013 23:39:36 +0100 Original-Received: by mail-qe0-f70.google.com with SMTP id 1sf1087845qec.5 for ; Tue, 05 Feb 2013 14:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:x-received:received-spf :mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type:content-transfer-encoding; bh=A0co25rosO3YN1pPv+Zdq2MRX0ez/eqYpBujFEw8jE0=; b=03bo98+nkEEsgx0Jo+81Gsq3KpX8UWJw+HmsBbOtW4Xugi99WEzRsKrjaT8+iiMXLd 9n/XaB1SfwLHSFtcYLw7564frhM2BAhwj2rNeh6O2CtOm62TKDfqxUzW49j/07IR7nwE QAo5cKVbOFu21sNufkzkKL6sP6nopkwgnOrm0icOOO1FsTW19W4Fmywf6jJ3YkhJLFWa /wnGWdQqsjQeGIgvLPXaCHzHVw/pxa3g7oDm1cW5EGDhR6xlnHXsQHmrXKtQkgwbjf7N FOPdfySYm3PJs8VpnUXBYKu X-Received: by 10.224.189.78 with SMTP id dd14mr14081533qab.0.1360103957292; Tue, 05 Feb 2013 14:39:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.133.102 with SMTP id pb6ls171401qeb.75.gmail; Tue, 05 Feb 2013 14:39:16 -0800 (PST) X-Received: by 10.224.177.6 with SMTP id bg6mr2967400qab.78.1360103956868; Tue, 05 Feb 2013 14:39:16 -0800 (PST) X-Received: by 10.224.177.6 with SMTP id bg6mr2967398qab.78.1360103956845; Tue, 05 Feb 2013 14:39:16 -0800 (PST) Original-Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by mx.google.com with ESMTPS id e7si3703048qao.22.2013.02.05.14.39.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Feb 2013 14:39:16 -0800 (PST) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.128.49 as permitted sender) client-ip=209.85.128.49; Original-Received: by mail-qe0-f49.google.com with SMTP id 5so354420qea.36 for ; Tue, 05 Feb 2013 14:39:16 -0800 (PST) X-Received: by 10.224.31.205 with SMTP id z13mr20521757qac.76.1360103956625; Tue, 05 Feb 2013 14:39:16 -0800 (PST) Original-Received: by 10.49.87.168 with HTTP; Tue, 5 Feb 2013 14:39:16 -0800 (PST) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.128.49 as permitted sender) smtp.mail=tvaneerd@gmail.com; dkim=pass header.i=@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:2743 Archived-At: On Tue, Feb 5, 2013 at 3:02 PM, Andrzej Krzemie=F1ski = wrote: >> >> Is optional a RegularType? > > > I am not sure how to answer the question. Different people have slightly > different expectations of a regular type. That's why I cc'ed Sean Parent :-) Let's go with Stepanov, via http://www.stepanovpapers.com/DeSt98.pdf and Elements of Programming (www.elementsofprogramming.com) > optional has: > > default ctor > destructor > copy/move constructor (shallow) > copy/move assignment (shallow) > equality comparison (deep, provided that T is comparable) > it is not swappable yet, but I intend to add a shallow swap > > I am not not sure what semantic requirements a RegularType requires. To summarize Stepanov, mainly the semantics of int w.r.t. copy, assignment, and equality: T b =3D ...; T a =3D b; assert(a =3D=3D b); T c =3D b; change(a); assert(c =3D=3D b && a !=3D b); oh, and since I happen to always use construction above, I should mention assignment and construction yield the same results, ie: T a; a =3D b; <=3D=3D> T a =3D b; (he also requires less-than, but we can ignore that here) > The > value compared by operator=3D=3D is not under control of the optional obj= ect: it > can change "asynchronously". Let's limit our discussion to optionals over Ts where T is Regular. I agree there is not much we can do when T is not Regular. So in general, optional is Regular if T is Regular, I think. (?) > Also the copy/move operations are not > compatible with operator=3D=3D: the former are shallow, the latter is dee= p. > That the part I'm wondering about. I guess the key thing is that even though T is regular, T & isn't, as the final a !=3D b assert fails. Using 'int' and 'int &' we get: int target =3D 17; int & b =3D target; int & a =3D b; assert(a =3D=3D b); int & c =3D b; change(a); assert(c =3D=3D b && a !=3D b); // fails! as a =3D=3D b So does optional have the same semantics as int & (at least when the optional is engaged)? Except optional allows rebinding, whereas int & does not. Why not allow mixed assignment even? optional oi =3D target; oi =3D 123; that would be consistent with int &. I guess it gets confusing with the rebinding? int alternate =3D 21; int another =3D 35; oi =3D alternate; assert(target =3D=3D 21); oi =3D optional(another); oi =3D 42; assert(target !=3D 42); assert(another =3D=3D 42); I could live with mixed assignment. Moreover, I think it is "more correct"= .. So generic code wants to work generically (obviously) and typically on RegularTypes. optional<> is not always regular. How do I compile-time check that the target type is a reference? I assume there is optional<>::value_type. I don't expect that I can easily test that the value_type is regular (in general) but I can check if it is a reference. Don't know what that says about your first argument in favour of optional references: "optional can be used in generic code, were T can be either a reference or an object" I don't think generic code will typically work with both optional and optional interchangeably. Nor do I think much generic code works with T and T& interchangeably. The semantics are different, there isn't much of interest the generic code can reliably do. By the way, now that I've (re)read the Auxiliary part about optional references, I see you've covered much of this. Hope I wasn't repeating too much, and something of the above was helpful. And also the example: void assign_norebind(optional& optref, T& obj) { if (optref) *optref =3D obj; else optref.emplace(obj); } Is that really useful? It is 2 totally different semantics ("targetting" vs "set-value-of-target") rolled into one. Tony --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/?hl=3Den. .