220 2166 <73637060-56ab-476b-9822-9f70dd2bb714@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: optional, one more value or two states Date: Thu, 24 Jan 2013 11:30:44 -0800 (PST) Lines: 203 Approved: news@gmane.org Message-ID: <73637060-56ab-476b-9822-9f70dd2bb714@isocpp.org> References:

<51013FC6.9080907@bubblescope.net>

Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_440_15232459.1359055844694" X-Trace: ger.gmane.org 1359055847 29540 80.91.229.3 (24 Jan 2013 19:30:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jan 2013 19:30:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBZ4XQ2EAKGQEZY4C6HQ@isocpp.org Thu Jan 24 20:31:06 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TySVu-0007bB-JK for gclcip-std-proposals@m.gmane.org; Thu, 24 Jan 2013 20:31:06 +0100 Original-Received: by mail-ye0-f198.google.com with SMTP id l11sf15372899yen.9 for ; Thu, 24 Jan 2013 11:30:48 -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=y46JcKO9i0I0tHdELTFDa8z9kRJpNL8dgP+BSsET3nA=; b=IO6aUPNkiDzyNsFUa5FbR1i7liSPVXGXlYNtK5jJxMqlgBHtCnUgFUR4M+GFLoSypg n8+x1np22UqqTH3cict8xJqaOMWdJUnE7yx5MwGZO9/9lbdAtD8HWANz6cKpYbsGvWps eUEUV/DmYrbJiVPs4mqGiZL7MnikHkqNoXJ7PcYC640JpJ6AxCbf3yD+U4aRb/SjZ+rc ncXbhwRn3SAJK4GuXdgiKGMt7AGxYgR4PE3TXdklQOHPKW5FbPaFL/fEy1ihN7GGoVBq CYqR8Z7gqoOJvRvSVVzoglf0dNo74PmpNxTNvt4rEVN40fPg/WLHQ8JHTomc1JdK9w0q /+9w== X-Received: by 10.224.72.199 with SMTP id n7mr1485741qaj.5.1359055848728; Thu, 24 Jan 2013 11:30:48 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.119.162 with SMTP id kv2ls786346qeb.86.gmail; Thu, 24 Jan 2013 11:30:46 -0800 (PST) X-Received: by 10.49.116.1 with SMTP id js1mr723020qeb.19.1359055846491; Thu, 24 Jan 2013 11:30:46 -0800 (PST) In-Reply-To: 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:2166 Archived-At: ------=_Part_440_15232459.1359055844694 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 24 stycznia 2013 20:17:55 UTC+1 u=BFytkownik Zhihao Yuan= =20 napisa=B3: > > On Thu, Jan 24, 2013 at 12:35 PM, Zhihao Yuan >=20 > wrote:=20 > >> Which functional languages have user-defined implicit conversions at= =20 > all?=20 > >=20 > > Scala.=20 > > Besides, let me say a few words about implicit conversion.=20 > An implicit conversion from T to U should ensure that T is-a=20 > U, the possible values of T is a subset of the possible values=20 > of U, T -> U holds a partial-order relation.=20 > > And you will see any implicit conversion violating the above=20 > statements is a flaw.=20 > > Narrowing conversion. Int type T can be converted to int type=20 > U even if T has a larger range. One of the criticism of C++'s=20 > type safety.=20 > > char const* to std::string. Pointer is not a collection of chars,=20 > while std::string is. So `string(strdup("aha"))` result in a memory=20 > leak. And such a conversion implies the `array to pointer`=20 > conversion, which makes "nu\0\l" lost everything after '\0'.=20 > > "Those are C's probem/C has NUL-terminated strings from the=20 > stone age. " OK. I'm not trying to argue these. But keep this=20 > in mind: an implicit conversion from T to U without T <=3D U=20 > is a flaw.=20 > > Let's go back to `std::optional`. So that's why I ask, what is=20 > optional. A T with a larger range, or a T with two states.=20 > If (1), then an implicit conversion is OK, but I suggest that=20 > to ensure "undefined =3D=3D undefined" (JavaScript), or=20 > "None =3D=3D None" (Python). Although I don't like it, and I don't=20 > think it's safe, but this is *the* extended value.=20 > > If optional is a T with two states, things go easy. We have=20 > numerous successful use cases in the functional programming=20 > area.=20 > Ok, now the question is clearer, although the "T with two states" kills me.= =20 The design of boost::optional and now std::optional is to allow your option= =20 1 (nullopt is just one other value of T) wherever it is reasonably safe: optional i =3D 0; optional j =3D nullopt; i =3D 0; j =3D nullopt; i =3D=3D 0; i =3D=3D nullopt; the mixed equality comparison is allowed in boost::optional and allowing it= =20 in std::optional is still under discussion. We cannot allow this uniformity= =20 for reading the optional value though. Also the semantics of operator=3D=3D= and=20 operator< clearly indicate the "one additional value of T". I am not sure= =20 if this answers your question. --=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. ------=_Part_440_15232459.1359055844694 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu czwartek, 24 stycznia 2013 20:17:55 UTC+1 u=BFytkownik Zhiha= o Yuan napisa=B3:

On Thu, Jan 2= 4, 2013 at 12:35 PM, Zhihao Yuan <lic...@gmail.com> wrote:
>> Which functional languages have user-defined implicit conversi= ons at all?
>
> Scala.

Besides, let me say a few words about implicit conversion.
An implicit conversion from T to U should ensure that T is-a
U, the possible values of T is a subset of the possible values
of U, T -> U holds a partial-order relation.

And you will see any implicit conversion violating the above
statements is a flaw.

Narrowing conversion. Int type T can be converted to int type
U even if T has a larger range. One of the criticism of C++'s
type safety.

char const* to std::string. Pointer is not a collection of chars,
while std::string is. So `string(strdup("aha"))` result in a memo= ry
leak. And such a conversion implies the `array to pointer`
conversion, which makes "nu\0\l" lost everything after '\0'.

"Those are C's probem/C has NUL-terminated strings from the
stone age. " OK. I'm not trying to argue these. But k= eep this
in mind: an implicit conversion from T to U without T <=3D U
is a flaw.

Let's go back to `std::optional`. So that's why I ask, what is
optional<T>. A T with a larger range, or a T with two state= s.
If (1), then an implicit conversion is OK, but I suggest that
to ensure "undefined =3D=3D undefined" (JavaScript), or
"None =3D=3D None" (Python). Although I don't like it, and I don'= t
think it's safe, but this is *the* extended value.

If optional<T> is a T with two states, things go easy. We h= ave
numerous successful use cases in the functional programming
area.

Ok, now the question is clearer, although the "T = with two states" kills me. The design of boost::optional and now std::optio= nal is to allow your option 1 (nullopt is just one other value of T) wherev= er it is reasonably safe:

optional<int> i =3D 0;
optional<int><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> j =3D nullopt;

i =3D 0;j =3D nullopt;

i =3D=3D 0;
i =3D=3D nullopt;

the mixed equality comparison is allowed= in boost::optional and allowing it in std::optional is still under discuss= ion. We cannot allow this uniformity for reading the optional value though.= Also the semantics of operator=3D=3D and operator< clearly indicate the= "one additional value of T". I am not sure if this answers your question.<= br>

--

---
You received this message because you are subscribed to the Google Groups &= quot;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-pro= posals/?hl=3Den.

------=_Part_440_15232459.1359055844694-- .