220 19950 article Path: news.gmane.org!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Address of a reference: determining the value category of what it refers? Date: Fri, 21 Aug 2015 16:49:43 -0700 Lines: 81 Approved: news@gmane.org Message-ID: References: <76fe342f-3342-4355-af20-1c41b21e54aa@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33d9520afe29051ddaec9c X-Trace: ger.gmane.org 1440200987 31137 80.91.229.3 (21 Aug 2015 23:49:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2015 23:49:47 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBGHS32XAKGQE6N27XOI@isocpp.org Sat Aug 22 01:49:46 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSw49-0000tc-Q8 for gclcip-std-proposals@m.gmane.org; Sat, 22 Aug 2015 01:49:45 +0200 Original-Received: by igbjg10 with SMTP id jg10sf49757132igb.0 for ; Fri, 21 Aug 2015 16:49:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Udes1kxam7f8W4cdwCxMTbZUvMN4aP0GyG8oRrVwUDo=; b=CsZTLuQSJvIjYK7saPXjmr7GiisHXFEuHzZyVGwxeTioeQDLwLjm9UBiy3e0Y3wfKW sMX45+v2+qRftUbM/CV9LqJ2BMZ/CARunoSxl8ufxDVoi16NsyYS412yiKbWU9Co2nXv odkpqvSzXgvckZRvgiuNEt+IsnqcwfwLSKg2qcY49Iqco1B9dTPZNs5WNLogCbuadCoY s8qpukt82j9fDytfRmB0oILTuN6ZEZpBH/OrUsga2ITyBLZSNSWVPPZWZxD9vjjY9dBS 2Zcvqjstu4twL5E4FIIDgnmsk7IAWRidBVoS057YQSSVjJS+ZSYVusJxZABfO3RCYMbb WbXQ== X-Gm-Message-State: ALoCoQlKowogESuLrozeP4zEFWYEOg16tuN5eK692s69LMvLQzootflI/csNykRRnLuG53VkG9e1 X-Received: by 10.50.50.137 with SMTP id c9mr5016838igo.11.1440200984769; Fri, 21 Aug 2015 16:49:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.134.197 with SMTP id pm5ls1656903obb.86.gmail; Fri, 21 Aug 2015 16:49:44 -0700 (PDT) X-Received: by 10.182.144.194 with SMTP id so2mr9859450obb.51.1440200984073; Fri, 21 Aug 2015 16:49:44 -0700 (PDT) Original-Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com. [2607:f8b0:4003:c01::22a]) by mx.google.com with ESMTPS id x189si6827215oix.20.2015.08.21.16.49.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2015 16:49:44 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c01::22a as permitted sender) client-ip=2607:f8b0:4003:c01::22a; Original-Received: by obbhe7 with SMTP id he7so71402467obb.0 for ; Fri, 21 Aug 2015 16:49:43 -0700 (PDT) X-Received: by 10.60.93.99 with SMTP id ct3mr10786804oeb.56.1440200983756; Fri, 21 Aug 2015 16:49:43 -0700 (PDT) Original-Received: by 10.60.27.194 with HTTP; Fri, 21 Aug 2015 16:49:43 -0700 (PDT) In-Reply-To: <76fe342f-3342-4355-af20-1c41b21e54aa@isocpp.org> X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c01::22a as permitted sender) smtp.mailfrom=calabrese@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Matt Calabrese Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19950 Archived-At: --047d7b33d9520afe29051ddaec9c Content-Type: text/plain; charset=UTF-8 On Fri, Aug 21, 2015 at 4:24 PM, NDos Dannyu wrote: > > &r and &lcr prints out &i, but &rcr and &rr have their own unique value. > It doesn't make sense, as what rcr and rr refer to are what don't have an > address, they are just zeros. > So, I suggest them to be nullptrs. More precisely, in terms of built-in > operators: > I don't understand the purpose of this and it would break otherwise sound code. Taking the address of an object in C++ doesn't yield a null pointer, and users should be able to dereference the address of an object to retrieve the original value. Similarly, different objects of the same type have unique addresses. What you propose would break these assumption and associated uses, and do so in a subtle way. This also wouldn't really be implementable anyway, IIUC, since soon as you introduce a level of indirection by passing the object by reference to a function, you'd no longer know that it referred to a literal (what would you expect to see if you took the address of the parameter from inside of the function). I don't really see the purpose of this change, but whatever it is, there is probably a more direct solution to your needs than changing the behavior of & -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b33d9520afe29051ddaec9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 21, 2015 at 4:24 PM, NDos Dannyu <ndospark320@naver.com>= ; wrote:
&a= mp;r and &lcr prints out &i, but &rcr and &rr have their ow= n unique value. It doesn't make sense, as what rcr and rr refer to are = what don't have an address, they are just zeros.
So, I sugges= t them to be nullptrs. More precisely, in terms of built-in operators:

I don't understand the pu= rpose of this and it would break otherwise sound code. Taking the address o= f an object in C++ doesn't yield a null pointer, and users should be ab= le to dereference the address of an object to retrieve the original value. = Similarly, different objects of the same type have unique addresses. What y= ou propose would break these assumption and associated uses, and do so in a= subtle way. This also wouldn't really be implementable anyway, IIUC, s= ince soon as you introduce a level of indirection by passing the object by = reference to a function, you'd no longer know that it referred to a lit= eral (what would you expect to see if you took the address of the parameter= from inside of the function).

I don't really = see the purpose of this change, but whatever it is, there is probably a mor= e direct solution to your needs than changing the behavior of &

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b33d9520afe29051ddaec9c-- .