220 27301 article Path: news.gmane.org!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: What should the semantic of wrapper classes be? Date: Tue, 26 Jul 2016 20:49:48 -0700 (PDT) Lines: 164 Approved: news@gmane.org Message-ID: References: <5b59502b-2a34-46dd-990e-1a748301018d@isocpp.org> <4258155.F5Eu8EN2ES@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3479_1290129648.1469591388718" X-Trace: ger.gmane.org 1469591398 12527 80.91.229.3 (27 Jul 2016 03:49:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2016 03:49:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBXO64C6AKGQERSRI7JA@isocpp.org Wed Jul 27 05:49:51 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bSFqw-00068a-VQ for gclcip-std-proposals@m.gmane.org; Wed, 27 Jul 2016 05:49:51 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id c127sf27218060qkf.3 for ; Tue, 26 Jul 2016 20:49:50 -0700 (PDT) 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=XQU4BgECv0cBfzAkKlnMSQRPrFuqaERwibLTOUPwjPw=; b=E7bZL1zbJlx9NIWMBNTOLqLD4pCp3wHdWBBnrbxYvHBbyzG3oBEbQbEVo2E5h4pYhv MfcOtNJHYDESKYVBmf8hLgLVWbOqpWAHD3Os3X+3Im4i5gPAh36bYC/ONaOtmEUZIqxZ ChypD/wIq+Fn0bmDOBhTHVKDOTZ6tPp3m5YcVF8sSL71/auUTXBVcUENBCX69SXPr+9U BrSCcG1Bxj7mwLTG1WbpmQSQEogsIwnZBuKG+nHf3e0rDRYF+fbu9JJaBBpNfNHMs+t1 6uqrfR/kzQJrclADAU6UUWTzalTgSyuyORAz/KYIaMlU2hiEdKlWN37xXAVJzWE7UqTJ 5kQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=XQU4BgECv0cBfzAkKlnMSQRPrFuqaERwibLTOUPwjPw=; b=Rfb/e/M9wQzGbrbeGcq9DDxe3Zcr4NxyekRFvOJg+Sebyhb41xB5c/R17UP7jbQQVu VWnc1GgKWXbMdlyaAcsjW4/AQvvUCOmnNTgINUJ60sUIeetG217dYLcgNrYgyAPBF0gG kosu9Alv1BMbp65HdfY5YDzBi/CJTnqXy4vGktjD4B25Y03pNC1ogd/cztsXjjW+5ujv Sph+d3Re4hLtAKsb2wDktEM9tj8yATtaEn2hucfaJmYZxVFFlnJ/28t/cuf3HoqL7r6M 3Fck/EvyxoCnB37funnWKJ6SdentKXOBozV5xfq+PmZ9xjSEx3bh6X48xfVB4T5QU+g4 tUAA== 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: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=XQU4BgECv0cBfzAkKlnMSQRPrFuqaERwibLTOUPwjPw=; b=ccLPB7f54vc4CX1YB5FbJsp5rRFidFuOTtbhomak37vPbCCCEXiCKmTMDo+yL3+vCQ +vvyMCb0s5iTntUlGC2q/Se3c5Y58XFHSgcy5xrG5MMQdixF1CTGmUJwXGYr43jAb3zH 0gMbjBEPRa/haiaNIAiVlgWHAFKzpDMGbjYAviGQssapQeXyohq1f1FcMrr5dRHbwukK R71D0qRkVzwx5gC2HCD841N6paF78KtaulCG9F5BYfjjb2whWlHT07GVOEK6hk++LkKA WrhhCFAEPM+H5zxf23OmPb8H402euG5JLRLMo6hB8YCUCmwZ1WihzQ4RSBF/wuJ51msE Ib5w== X-Gm-Message-State: AEkoouvDU9BKptrsVSZNDWHJ/SI7s+DjjJedPl2waZ0fp4WbmgaxPWE3leynZmVn5ViUtw== X-Received: by 10.237.53.206 with SMTP id d14mr23977354qte.9.1469591389924; Tue, 26 Jul 2016 20:49:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.54.140 with SMTP id h12ls444863otc.40.gmail; Tue, 26 Jul 2016 20:49:49 -0700 (PDT) X-Received: by 10.157.29.72 with SMTP id m66mr1466906otm.20.1469591389248; Tue, 26 Jul 2016 20:49:49 -0700 (PDT) In-Reply-To: <4258155.F5Eu8EN2ES@tjmaciei-mobl1> X-Original-Sender: frankhb1989@gmail.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:27301 Archived-At: ------=_Part_3479_1290129648.1469591388718 Content-Type: multipart/alternative; boundary="----=_Part_3480_2066414520.1469591388718" ------=_Part_3480_2066414520.1469591388718 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC= +8=E4=B8=8A=E5=8D=8810:24:54=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF= =BC=9A > > On ter=C3=A7a-feira, 26 de julho de 2016 18:34:36 PDT Tony V E wrote:=20 > > So value should not exist. It should be collapsed to value= ..=20 > > const value is fine.=20 > >=20 > > But for value I assume the T lives within value.=20 > >=20 > > Alternatively, value should work the same as const value.= =20 > > I still don't understand the point of value. If T stores a value, why= =20 > do we=20 > need value? It stands to reason that value does something extra, on= =20 > top=20 > of what T can do. That something extra is quite important and may affect= =20 > what=20 > a value might be.=20 > > Should I understand it like optional, which can store a T, but it can= =20 > also=20 > be disengaged and store nothing? optional makes no sense.=20 > > Or maybe like atomic. Here we have that atomic is the same as= =20 > const atomic.=20 > If you want to assume that T lives within lifetime of value, you perhaps= =20 have to also assume T stores a value, as I don't find another obvious way= =20 to guarantee the lifetime of T. Then value and value are=20 essentially different. Otherwise, if you only want to use value as rvalue of type T, then=20 value should always decay to value. However, then it will=20 behave more like a "reference". I'm not sure which kind of "value" is intended by the spelling. It is at=20 least confusing to me. If both use are needed, just use object type T as usual. Perhaps the only= =20 reason to wrap it is that operations on bit-fields are too limited, as they= =20 are not capable as operand of builitin& or bound to a reference, etc. Ugly. > --=20 > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 > Software Architect - Intel Open Source Technology Center=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/ed356443-8af2-47b0-8a7d-3ded47f70e12%40isocpp.or= g. ------=_Part_3480_2066414520.1469591388718 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8810:24:54=EF=BC=8CThiago Maciei= ra=E5=86=99=E9=81=93=EF=BC=9A
O= n ter=C3=A7a-feira, 26 de julho de 2016 18:34:36 PDT Tony V E wrote:
> So value<const T> should not exist. =C2=A0It should be colla= psed to value<T>.
> const value<T> is fine.
>=20
> But for value<T> I assume the T lives within value<T>.
>=20
> Alternatively, value<const T> should work the same as const = value<T>.

I still don't understand the point of value<T>. If T stores a= value, why do we=20
need value<T>? It stands to reason that value<T> does somet= hing extra, on top=20
of what T can do. That something extra is quite important and may affec= t what=20
a value<const T> might be.

Should I understand it like optional<T>, which can store a T, but= it can also=20
be disengaged and store nothing? optional<const int> makes no sen= se.

Or maybe like atomic<T>. Here we have that atomic<const T> = is the same as=20
const atomic<T>.
If you want to assume that T lives within lifetime of= value<T>, you perhaps have to also assume T stores a value, as I don= 't find another obvious way to guarantee the lifetime of T. Then value&= lt;T> and value<const T> are essentially different.
Otherwise, = if you only want to use value<T> as rvalue of type T, then value<c= onst T> should always decay to value<T>. However, then it will beh= ave more like a "reference".
I'm not sure which kind of &q= uot;value" is intended by the spelling. It is at least confusing to me= ..

If both use are needed, just use object type T as usual. Perhaps t= he only reason to wrap it is that operations on bit-fields are too limited,= as they are not capable as operand of builitin& or bound to a referenc= e, etc. Ugly.


--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--
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/ed356443-8af2-47b0-8a7d-3ded47f70e12= %40isocpp.org.
------=_Part_3480_2066414520.1469591388718-- ------=_Part_3479_1290129648.1469591388718-- .