220 2442 article Path: news.gmane.org!not-for-mail From: Daniel James Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional, one more value or two states Date: Mon, 28 Jan 2013 19:53:27 +0000 Lines: 101 Approved: news@gmane.org Message-ID: References:

<2c2b9360-8e5e-422d-9b85-124bd947b004@isocpp.org> <123b9f65-12fd-4285-bb6c-cfee383d4552@isocpp.org>

<687e9b13-cec1-4776-8fa2-6ad15aaf5e24@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1359402806 4873 80.91.229.3 (28 Jan 2013 19:53:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jan 2013 19:53:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGPB3VVUAGBBOFOTOEAKGQEMXRHJ3A@isocpp.org Mon Jan 28 20:53:46 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f72.google.com ([209.85.161.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tzum2-0002vA-4v for gclcip-std-proposals@m.gmane.org; Mon, 28 Jan 2013 20:53:46 +0100 Original-Received: by mail-fa0-f72.google.com with SMTP id s10sf3679497fas.7 for ; Mon, 28 Jan 2013 11:53:28 -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=p1ihZ5j8j3uPwgMyQQVPTYbxUIPmEXupahBRmYCj1GU=; b=KbKi2w4X66XUoKU1b1VOFEwp8u0KnQLymXwJgEzqf5pc9+HnrUXGbad7w8pauPlUfz IF/3rujw7OOilc7JNID+0KW9Tu+UV7CVVaEG/LeykbVTYhnLNCCNMFJw9HG5RVN3+tnG QFGEVOBcWN2InLHo85VIllwVUoTtDw/ebpLRtGmlJ5Q1UZwX4gc9cqN6ES7BDKzIaf2A gD85jZyhzug/CNj9iFVACC4GzA2nEV3iNUvvGkOwZRz7Q/ZWKpKCJL2NQmUzKaaxX3UQ y12UaVkK+m3ovzJkACadthV X-Received: by 10.180.78.36 with SMTP id y4mr2194588wiw.1.1359402808282; Mon, 28 Jan 2013 11:53:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.100.133 with SMTP id ey5ls1052854wib.32.gmail; Mon, 28 Jan 2013 11:53:27 -0800 (PST) X-Received: by 10.194.174.196 with SMTP id bu4mr23325258wjc.35.1359402807798; Mon, 28 Jan 2013 11:53:27 -0800 (PST) X-Received: by 10.194.174.196 with SMTP id bu4mr23325256wjc.35.1359402807785; Mon, 28 Jan 2013 11:53:27 -0800 (PST) Original-Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx.google.com with ESMTPS id fq9si2853331wib.95.2013.01.28.11.53.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 11:53:27 -0800 (PST) Received-SPF: pass (google.com: domain of dnljms@gmail.com designates 74.125.82.51 as permitted sender) client-ip=74.125.82.51; Original-Received: by mail-wg0-f51.google.com with SMTP id 8so2010698wgl.30 for ; Mon, 28 Jan 2013 11:53:27 -0800 (PST) X-Received: by 10.194.88.202 with SMTP id bi10mr23403952wjb.5.1359402807685; Mon, 28 Jan 2013 11:53:27 -0800 (PST) Original-Received: by 10.194.46.7 with HTTP; Mon, 28 Jan 2013 11:53:27 -0800 (PST) In-Reply-To: <687e9b13-cec1-4776-8fa2-6ad15aaf5e24@isocpp.org> X-Original-Sender: dnljms@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dnljms@gmail.com designates 74.125.82.51 as permitted sender) smtp.mail=dnljms@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:2442 Archived-At: On 28 January 2013 10:01, Andrzej Krzemie=C5=84ski wro= te: > > This is how i see it. We all first learned how a raw pointer works, and w= e > keep in mind all its semantics. Then, we get shared_ptr, and it is differ= ent > than a raw pointer, but it is still significantly similar, that we can st= ill > call it a pointer. Then, we have unique_ptr, which is even more different= .. > For instance, your example: > > > auto x =3D y; > *x =3D 2; > > fails to compile if y is a unique_ptr. Failing to compile is fine. If a class doesn't meet the expected behaviour, then that's the best thing to do. > And there is enough similarities to have some > algorithms work both on pointers and optional. During these discussions I > was already able to identify at least four algorithms: > auto less_pointees(NullableProxy const& x, NullableProxy const& y) > auto equal_pointees(NullableProxy const& x, NullableProxy const& y) These operations are supported by ranges. And are of limited value for pointers. (Also, of course, proxies don't have pointees, pointers do). > auto get_value_or(NullableProxy && np, U && val) > auto to_pointer(NullableProxy && np) Calling these "algorithms" is certainly stretching the term, providing a utility to do this for both optionals and pointers is pretty trivial. There's no need for them to be generic in the manner that 'transform' is. Also, 'to_pointer' is perhaps too easy to confuse with 'get_pointer'. I'm really not convinced. > auto less_value(NullableProxy const& x, U && y) Isn't this just 'less_pointees' with a cast? > Thus, because Identifying the common parts is useful, it is beneficial to > identify what aspects of pointers are relevant for "abstracting" type > requirements NullableProxy, and which aren't. And conversely, there are s= ome > aspects of pointer semantics that are irrelevant (and can be dropped) whe= n > abstracting the concept. Just identifying common parts is not sufficiently useful. It has to be done for a good reason. Otherwise this is premature generalization, which can lead to unnecessary complexity. > We need operator* to express algorithms common to > NullablePrioxy concepts, but we are only interested in one aspect of it: > giving us the reference to the hidden value (regardless of where it is > located and how it is copied -- NullableProxies do not have to be copyabl= e > or moveable). The other parts of the semantics of pointers are dropped wh= en > abstracting. You don't *need* operator* for anything, you just want it. The problem is you can't just drop copying, it's just too easy to use it and expect it to do the predictable thing without realising that you've done that. > Typically you would expect of operator* (for multiplication) to be > commutative. Do you consider providing operator* for matrix multiplicatio= n a > design error then? Not at all, matrix multiplication has a long and well established history. That's very important and should be respected. Optional as a pointer does not. It's just a cheap way to avoid typing 5 characters. I'm also have no problem with using 'operator/' with paths, as you're not going to mix it up with numerical division. And for a similar reason, I don't have a problem with the use of 'operator|' for 'piping' ranges. Matrices are perhaps a bit more likely to be mixed up with numbers, but if they are, then I think it would usually caught be by the type system. And it's unlikely to lead to the subtle bugs that can happen when mixing up reference and value types. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To post to this group, send email to std-proposals@isocpp.org. To unsubscribe from this group, send email to std-proposals+unsubscribe@iso= cpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/?hl=3Den. .