220 8619 article Path: news.gmane.org!not-for-mail From: Jeffrey Yasskin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Wed, 15 Jan 2014 12:42:20 -0800 Lines: 94 Approved: news@gmane.org Message-ID: References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <2875722.TjfBuHt6Pp@tjmaciei-mobl2> <2685690.E3vksNc10o@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1389818558 9887 80.91.229.3 (15 Jan 2014 20:42:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 20:42:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBQPF3OLAKGQEJCLUBCQ@isocpp.org Wed Jan 15 21:42:47 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f71.google.com ([209.85.160.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W3XIS-0000Sd-5B for gclcip-std-proposals@m.gmane.org; Wed, 15 Jan 2014 21:42:44 +0100 Original-Received: by mail-pb0-f71.google.com with SMTP id uo5sf3496069pbc.10 for ; Wed, 15 Jan 2014 12:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=Zf9STc5Q0WJd5wnqOvDYgpSz3aUaTpKNlHEBwRokxN4=; b=EGjemGFBZawvKSRZ2rdklJXRbNQ0Ew5o+Wu3BI6kkXdyYrFfy5kMP0wXczIY88hdvZ 9+0i5qmW16+SusmaOK4/7TM6wCucvSzVCw7O/V2Rzb9AU1ofiDqhGrpL8sTqMXVL62Ar ZtpSxeLyEnkjqdwndcyEBLU18jYasKO2KkyM3yMIRRv1Zlj37Dfmy4tRyLr78of3ps7n +SNHIUWGrqnp5D/6EgrzJrRLELGB8jQ51Fwsjpkl/KC17QCFHaLuG8CUwDBuVmc6K7IP peivcGmnSLDfO203vpFSKSBUSSKCOqgo6YrBSbjGp0aseEcirkTM1peO5zKszxDz+QfF UdKg== 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:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=Zf9STc5Q0WJd5wnqOvDYgpSz3aUaTpKNlHEBwRokxN4=; b=X9HEUsRp3pivq2O+BFE8optp9JngIbyzMOFByBARNX7gqfc34Rrux9ikUVXlztKljV hLsg+QWcH+6koiPSVyMHxZdAG2dT+kaZvSqW8XO3CODQa88PnJYzeMct6/7OAj1oNjXk +IAx+/fXh/m6KoR/TAxt0q4Op7uVkUOe/i/F6GnFNgjJz0+ZZQ6rYAHLXsZR84F3Hpcj g+JACajjSb/RXbcnySG/2n77OASic2mF1ygUCsayGEbHGvketaPeHxL9i4qtzxE9epgV kbp0uLWU+NoH5nk+Zb9hsqIwIeOSnzkFOaaTpgre6CvCCPa1w4GL9C+WnACLb8PiSsFo jwVQ== X-Gm-Message-State: ALoCoQmImU2J58z7fTJVCaNpXrRMZKTwM83f1tQtKeSkfV/nBgAM6gVTHkQMoYCe9ILnYvUri0a8 X-Received: by 10.66.222.105 with SMTP id ql9mr1848162pac.9.1389818562120; Wed, 15 Jan 2014 12:42:42 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.51.44 with SMTP id t41ls23850qga.86.gmail; Wed, 15 Jan 2014 12:42:41 -0800 (PST) X-Received: by 10.140.100.196 with SMTP id s62mr1341019qge.115.1389818561395; Wed, 15 Jan 2014 12:42:41 -0800 (PST) Original-Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [2607:f8b0:400d:c01::22e]) by mx.google.com with ESMTPS id j3si693074qaf.101.2014.01.15.12.42.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 12:42:41 -0800 (PST) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c01::22e as permitted sender) client-ip=2607:f8b0:400d:c01::22e; Original-Received: by mail-qc0-f174.google.com with SMTP id x13so1479471qcv.19 for ; Wed, 15 Jan 2014 12:42:41 -0800 (PST) X-Received: by 10.224.14.129 with SMTP id g1mr8716839qaa.42.1389818560952; Wed, 15 Jan 2014 12:42:40 -0800 (PST) Original-Received: by 10.229.208.138 with HTTP; Wed, 15 Jan 2014 12:42:20 -0800 (PST) In-Reply-To: <2685690.E3vksNc10o@tjmaciei-mobl2> X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c01::22e as permitted sender) smtp.mail=jyasskin@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8619 Archived-At: On Wed, Jan 15, 2014 at 11:45 AM, Thiago Macieira wrote: > On quarta-feira, 15 de janeiro de 2014 10:26:14, Jeffrey Yasskin wrote: >> Can you look over some of the uses of isNull() in QT and see what >> fraction are ones where both empty and null are possible values, and >> the distinction is useful rather than just forcing the API to document >> which one is used? > > The far majority of the cases, people just need the empty case. That's what we > recommend. And unless some API in specific documents the distinction, using > isEmpty() is the right thing to do. > > The null option comes in handy when you need to distinguish a field that might > be present but empty from a field that isn't present. QUrl makes use of that > and the equivalent std::networking::uri proposal just uses > std::optional (String is a template). For example: > > QUrl url1("foo:/"), url2("foo://@/?#"); > QString query1 = url1.query(), query2 = url2.query(); > > Both query1 and query2 are empty, but only query1 is null, indicating that the > query was not present. The same applies to userInfo(), host(), and fragment(), > and would apply to authority() if the "@" weren't present. > > And you can do: > > url1.setQuery(""); > url2.setQuery(QString()); > > to invert the situation. > > The other common case for using nulls is in QVariant and that comes from the > QtSql module: all entries are returned as QVariants and they need to support > database tables that don't contain "NOT NULL" (that is, are nullable). So > QVariant can contain a null int that is different from a zero: > > QVariant v1, v2{0}; > v1.convert(QVariant::Int); > // v1.isNull() == true; v2.isNull() == false > > We don't recommend relying on the nullness of a string. We only condone on the > above cases I described, but I wouldn't be surprised to find more uses. And, > trust me, there's quite a lot of headache involved in keeping the nullness of > certain types across transformations: > > QString().toUtf8().isNull() == true; > QString("").toUtf8().isNull() == false; > > And then there are weird questions like: > - does a null QString compare equal to an empty one? (yes) > - does a null QString startsWith() an empty one? Does the opposite? > - same for endsWith(), contains(), indexOf() > - is QString().left(1) null? How about QString().left(0)? > - and what about QString("hello").left(0)? > - if left, right and mid can return null, can leftRef, rightRef and midRef > (which return QStringRef)? > > I don't know the answer to most of those questions, which means I would > recommend no one rely on a specific behaviour. > > Most of it is unit-tested so we don't break it: > http://code.woboq.org/qt5/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp.html#_ZN11tst_QString10startsWithEv > http://code.woboq.org/qt5/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp.html#_ZN11tst_QString8endsWithEv > http://code.woboq.org/qt5/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp.html#_ZN11tst_QString4leftEv > http://code.woboq.org/qt5/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp.html#_ZN11tst_QString7leftRefEv > > and what isn't tested I'd feel free to change behaviour at any time. Thanks for the detailed discussion of QT's use. I agree there are some times when "not present" is different from "empty", but the fact that in "The far majority of the cases, people just need the empty case" makes me think that the string_view proposal makes the right choice. It's true that this means existing classes like QStringRef can't just become typedefs, but my goal here has been to learn from existing practice so that the standard can avoid making the same mistakes. optional<> is always available for cases like SQL and URLs, and using it means that the unusual case is called out rather than hiding inside the same type used for the usual case. Thanks again for trying it out, Jeffrey P.S. Other people need to make a stronger argument than "sometimes it is convenient". Give concrete examples like Thiago did, or I can't do anything with your email. -- --- 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/. .