220 2934 <63327756-bb52-4463-9cbf-0f895ecdd910@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::optional -- request for feedback on the wording Date: Mon, 18 Feb 2013 08:42:24 -0800 (PST) Lines: 329 Approved: news@gmane.org Message-ID: <63327756-bb52-4463-9cbf-0f895ecdd910@isocpp.org> References: <511FFA5B.7050204@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_521_25082555.1361205744491" X-Trace: ger.gmane.org 1361205750 24819 80.91.229.3 (18 Feb 2013 16:42:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2013 16:42:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBB4NTRGEQKGQE4POOCRQ@isocpp.org Mon Feb 18 17:42:51 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7Tni-0004fC-Hz for gclcip-std-proposals@m.gmane.org; Mon, 18 Feb 2013 17:42:46 +0100 Original-Received: by mail-vc0-f198.google.com with SMTP id m8sf7617657vcd.5 for ; Mon, 18 Feb 2013 08:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=GwuvCbKuHfNs3DOeHB4G4bBuUlSbpHiuUlwXz8rBQDw=; b=c4e7YZY6/tc5Qp1MahJpxAe7pDV/1ArVhQnN5r4kBRTBuRkBw7Q0EYDhBbiRoDPdzi UyXIWC5l0P3mKeLEQRrU2D8kPtBFyyawA7SFW3/mhqiiCVuMSmlNGnKLOQVvCPFJ61XC j9CtCZxv3aPea5y3BsKu4EjC87YPE4yLwUJgUnjiBy/Qxa8ieS14dP79AzNOUL0ITrCt b2mHjUSP2KiKM6+Q0k6vlB1JYjVOL9fO4hf94Z2dPG4aDfd+eXBx685drq8w6QvsgOG8 tsEEePTfqREpbYFKTZlQWFA8WSClHjfaDAvlGiVLH9tbW5VsYzpyfjSdenLA0vh9Ioi/ qeJw== X-Received: by 10.224.17.140 with SMTP id s12mr9134560qaa.3.1361205745490; Mon, 18 Feb 2013 08:42:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.39.231 with SMTP id s7ls1764191qek.47.gmail; Mon, 18 Feb 2013 08:42:24 -0800 (PST) X-Received: by 10.49.34.135 with SMTP id z7mr777891qei.1.1361205744862; Mon, 18 Feb 2013 08:42:24 -0800 (PST) In-Reply-To: <511FFA5B.7050204@wanadoo.fr> X-Original-Sender: akrzemi1@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:2934 Archived-At: ------=_Part_521_25082555.1361205744491 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu sobota, 16 lutego 2013 22:30:03 UTC+1 u=BFytkownik Vicente J. Botet= =20 Escriba napisa=B3: > > Le 15/02/13 14:46, Andrzej Krzemie=F1ski a =E9crit : > =20 > Hi everyone, > We have updated the proposal based on recent feedback. I enclose the=20 > latest draft. It is also available at: > http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html > > We would appreciate your feedback, especially on the standardese. > > Hi, > > Next follows some remarks=20 > > * As optional references are part of the auxiliary proposal, shouldn't th= e=20 > following be removed from 20.5.1? > > An *optional object for lvalue reference types* is an object capable of= =20 > storing the address of another object. The address stored by the optional= =20 > object can be changed or set to a value that does not represent a valid= =20 > address.=20 > Thanks for the input Vicente. I will fix this one. =20 > > * optional::optional(const optional& rhs); > =20 > What about adding a post-condition on the copied value > false =3D=3D bool(rhs) || rhs.value() =3D=3D this->value() > I initially put it. But Tony observed that for non-regular types it cannot= =20 be guaranteed. The requirement that the contained value should be crated as= =20 though copy-initialized should be a sufficiently clear requirement.=20 > What about adding noexecpt > optional::optional(const optional& rhs) noecept(see below); > > Remarks: The expression inside noexcept is equivalent to:=20 > > is_nothrow_copy_constructible::value > > Again, initially a conditional noexcept was applied aggressively to nearly= =20 every function in the proposal. But we were advised to follow the Library= =20 style where only move operations and swap are (sometimes conditionally)=20 constexpr. We adapted to the Library style. > * optional::optional(const T& v); > =20 > I'm curious to know How the remark can be implemented in C++11 > =20 > Remarks: If T's selected constructor is a constexpr constructor, this=20 > constructor shall be a constexpr constructor. > This is tricky, but possible with the clever use of a unions. It is working= =20 in reference implementation: https://github.com/akrzemi1/Optional/ The overview of the solution is also provided at the end of the proposal.= =20 Implementations may also use implementation-specific additions to satisfy= =20 this guarantee. > What about adding a post-condition on the copied value > v =3D=3D this->value() > > What about noexcept(is_nothrow_copy_constructible::value) as before? > =20 > * There is an assignment from U, but not a constructor from U. Is this=20 > missing? > The assignment from U is not really an assignment from U. The remark says= =20 "The function shall not participate in overload resolution unless is_same::type, T>::value is true" Thus U is effectively T. The= =20 reason to provide such generic assignment and then constraining it so that= =20 effectively T =3D=3D U is to guarantee that assignment of the form o =3D {}= is=20 unambiguous > > * template constexpr bool operator=3D=3D(const optional& x, = const=20 > optional& y); > > > I don't understand the remark =20 > > Instantiations of this function template for which *x =3D=3D *y is a core= =20 > constant expression, shall be constexpr functions. > Is the function a constexpr or not? > In the Standard, sect 7.1.5, para 6 we have: =20 If the instantiated template specialization of a constexpr function=20 > template or member function of a class > template would fail to satisfy the requirements for a constexpr function= =20 > or constexpr constructor, that > specialization is not a constexpr function or constexpr constructor. [ * > Note:* If the function is a member > function it will still be const as described below. *--end note* ] If no= =20 > specialization of the template would > yield a constexpr function or constexpr constructor, the program is=20 > ill-formed; no diagnostic required. > This gives implementation the freedom to provide a constexpr function=20 templates whose instantiations are not constexpr functions. We want to=20 limit this freedom.=20 Regards, &rzej --=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. ------=_Part_521_25082555.1361205744491 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu sobota, 16 lutego 2013 22:30:03 UTC+1 u=BFytkownik Vicente J= .. Botet Escriba napisa=B3:
=20 =20 =20
Le 15/02/13 14:46, Andrzej Krzemie=F1ski a =E9crit :
Hi everyone,
We have updated the proposal based on recent feedback. I enclose the latest draft. It is also available at:
http://kojot.sggw.waw.pl/~akrzemi1/o= ptional/tr2.optional.proposal.html

We would appreciate your feedback, especially on the standardese.


Hi,

Next follows some remarks

* As optional references are part of the auxiliary proposal, shouldn't the following be removed from 20.5.1?

=20 An optional object for lvalue reference types is an object capable of storing the address of another object. The address stored by the optional object can be changed or set to a value that does not represent a valid address.

Thanks f= or the input Vicente. I will fix this one.
 

=20

* optional<T>::optional(const optional<T>& rhs);

What about adding a post-condition on the copied value
=20 false =3D=3D bool(rhs) || rhs.value() =3D=3D this->value()


I initially put i= t. But Tony observed that for non-regular types it cannot be guaranteed. Th= e requirement that the contained value should be crated as though copy-init= ialized should be a sufficiently clear requirement.
<= p>

What about adding noexecpt
optional<T>::optional(const optional<T>& rhs= ) noecept(see below);

=20 Remarks: The expression inside noexcept is equivalent to: =20 
is_nothrow_copy_constructible<T>::value
<= /code>

Again, initially a conditional noexcept w= as applied aggressively to nearly every function in the proposal. But we we= re advised to follow the Library style where only move operations and swap = are (sometimes conditionally) constexpr. We adapted to the Library style.

=20

* optional<T>::optional(const T& v);

I'm curious to know How the remark can be implemented in C++11
 =20

Remarks: If T's selected constructor is a constexpr constructor, this constructor shall be a constexpr constructor.

This is tricky, but possible with the clever u= se of a unions. It is working in reference implementation: https://github.c= om/akrzemi1/Optional/
The overview of the solution is also provided at t= he end of the proposal. Implementations may also use implementation-specifi= c additions to satisfy this guarantee.

What about adding a post-condition on the copied value
v =3D=3D this->value()

What about noexcept(is_nothrow_copy_constructible<T>::valu= e) as before?


* There is an assignment from U, but not a constructor from U. Is this missing?

The assignment fr= om U is not really an assignment from U. The remark says "The function shal= l not participate in overload resolution unless is_same<typename = remove_reference<U>::type, T>::value is true"= Thus U is effectively T. The reason to provide such generic assignment an= d then constraining it so that effectively T =3D=3D U is to guarantee that assignment of the form o =3D {} is u= nambiguous



* template <class T> constexpr bool operator=3D=3D(const optional<T>& x, const optional<T>& y);


I don't understand the remark =20

Instantiations of this function template for which *x =3D=3D *y is a core constant expression, shall be constexpr= functions.

Is the function a constexpr or not?
=

In the Standard, sect 7.1.5, para 6 we have: 

If the instantiated temp= late specialization of a constexpr function or constexpr constructor, that
speci= alization is not a cons= texpr function or constexpr function or constexpr constructor, the= program is ill-formed; no diagnostic required.

Th= is gives implementation the freedom to provide a constexpr function templat= es whose instantiations are not constexpr functions. We want to limit this = freedom.

Regards,
&rzej

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
------=_Part_521_25082555.1361205744491-- .