220 10563 <53671843.4030007@lingnu.com> article Path: news.gmane.org!not-for-mail From: Shachar Shemesh Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Suggested new operator>> for istreams Date: Mon, 05 May 2014 07:49:07 +0300 Organization: Lingnu Open Source Consulting Lines: 84 Approved: news@gmane.org Message-ID: <53671843.4030007@lingnu.com> References: <41af112c-cb6f-41e2-ad98-546af3fcdaf8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080206050509070700050105" X-Trace: ger.gmane.org 1399602571 17149 80.91.229.3 (9 May 2014 02:29:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 May 2014 02:29:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCT3NU7YUUMBBRFQTSNQKGQEWGDJMWY@isocpp.org Fri May 09 04:29:24 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WiaYt-00038r-9o for gclcip-std-proposals@m.gmane.org; Fri, 09 May 2014 04:29:23 +0200 Original-Received: by mail-lb0-f199.google.com with SMTP id q8sf2084089lbi.2 for ; Thu, 08 May 2014 19:29:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-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=S2cP5BNErDntjHOGjCeg0LNTYNvVYz1zapDQsT+yMT0=; b=Wo3fDksnj4lVcMrLbOlkc2Ql5wJ9TWE49bJ95tDD7sbgNkn41NTbjzQPnWrCrh32oe fZFxD7dmCoIkMLn0lI+fr3S/+MI0lr+KVTcxm6K0iCK9E4c9rgBF6TMQoAWCTOZjn2g6 iFAP0clkhXTzeAtZmAhkg7oKEr7HsOZ7DBRIdVVcxmdvLSoi3Bfmo0+hCX7Kdh5lCs37 GbCl9KWC26XKNS3gzh2rLuHo/g0Qtw636d2d+nzTYVsgtD2R3j9HwyzOpX7YQZl3717f SYw65eKcJTby4tk8IfHeJGjc+XtUF/PqP3y08jAMRz46NsxtUNrZ89LajGk4TjkBAT3t tChw== X-Gm-Message-State: ALoCoQn22MqniSY46cMqWNn5vk9ZMFV00IxSEJcBC31RdnICkM7Gb7XvWDSUeEdhMteNeKXME5Q2 X-Received: by 10.152.42.141 with SMTP id o13mr44281lal.7.1399265349649; Sun, 04 May 2014 21:49:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.75.42 with SMTP id z10ls10456wiv.31.canary; Sun, 04 May 2014 21:49:08 -0700 (PDT) X-Received: by 10.14.209.3 with SMTP id r3mr6005985eeo.27.1399265348125; Sun, 04 May 2014 21:49:08 -0700 (PDT) Original-Received: from han.lingnu.com (han.lingnu.com. [91.205.172.112]) by mx.google.com with ESMTP id t3si8741628eeg.91.2014.05.04.21.49.08 for ; Sun, 04 May 2014 21:49:08 -0700 (PDT) Received-SPF: none (google.com: shachar@lingnu.com does not designate permitted sender hosts) client-ip=91.205.172.112; Original-Received: from [IPv6:::1] (localhost [127.0.0.1]) by han.lingnu.com (Postfix) with ESMTPA id B051DC94F6 for ; Mon, 5 May 2014 07:49:07 +0300 (IDT) User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: X-Enigmail-Version: 1.6 X-Original-Sender: shachar@lingnu.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: shachar@lingnu.com does not designate permitted sender hosts) smtp.mail=shachar@lingnu.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:10563 Archived-At: This is a multi-part message in MIME format. --------------080206050509070700050105 Content-Type: text/plain; charset=UTF-8 On 04/05/14 23:41, Dietmar Kuhl wrote: > > I definitely agree with Richard: the distinction between const and > non-const types is far too subtle to use it as a distinction on > whether data should be skipped or read. I had implemented that at some > point as an extension and found that it picks up unexpected overloads > quite frequently. Can you, please, give an example of such a thing. This goes counter to my intuition of the language. The thing I liked most about this proposal is that it narrowly picked cases that would simply not compile before, without overstepping any existing code. I would love to see an example for where this is not the case. > More importantly, introducing these overloads may break existing code, > e.g., because no more conversions could be viable creating an > ambiguity for currently unambiguous code. Again, examples would be welcome. I don't see it. Shachar -- --- 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/. --------------080206050509070700050105 Content-Type: text/html; charset=UTF-8
On 04/05/14 23:41, Dietmar Kuhl wrote:

I definitely agree with Richard: the distinction between const and non-const types is far too subtle to use it as a distinction on whether data should be skipped or read. I had implemented that at some point as an extension and found that it picks up unexpected overloads quite frequently.
Can you, please, give an example of such a thing. This goes counter to my intuition of the language. The thing I liked most about this proposal is that it narrowly picked cases that would simply not compile before, without overstepping any existing code. I would love to see an example for where this is not the case.
More importantly, introducing these overloads may break existing code, e.g., because no more conversions could be viable creating an ambiguity for currently unambiguous code.
Again, examples would be welcome. I don't see it.

Shachar

--

---
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/.
--------------080206050509070700050105-- .