220 26813 article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: auto type deduction for *_cast return argument Date: Tue, 12 Jul 2016 09:24:30 -0700 (PDT) Lines: 238 Approved: news@gmane.org Message-ID: References: <58140e46-2adc-4eac-8f51-72d3685cdf0b@isocpp.org> <7E3409C2-A2AC-4562-BB06-6D5D5ACE8AC8@gmail.com> <00caca39-d36a-475c-840f-79759e99265d@isocpp.org> <4ac3803f-a87d-4551-947f-43f106bdda20@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_273_1952398638.1468340670505" X-Trace: ger.gmane.org 1468340677 17879 80.91.229.3 (12 Jul 2016 16:24:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Jul 2016 16:24:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBP5TSS6AKGQE6SPVMXQ@isocpp.org Tue Jul 12 18:24:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f71.google.com ([209.85.214.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bN0U5-00054j-Lt for gclcip-std-proposals@m.gmane.org; Tue, 12 Jul 2016 18:24:33 +0200 Original-Received: by mail-it0-f71.google.com with SMTP id f6sf38521315ith.3 for ; Tue, 12 Jul 2016 09:24:33 -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=TEG0aX6phCBqdQm/xqfF62FVd9Ou9jjFwxo2esPZStU=; b=Uc6wZ4uXBzliqDoVagxBlK7UAIy98NLkgPRSaabsbGA+sfbjX5EdkzjBWcXeazmKNn vLeYCfQXP7aAUtD+nZ2P99cdDtLmFnxsqUIkz+KlsomfewdU247P3K/Ka+yHTMfhSDK4 Jj8oGyUI55H/Rzh+Hx+GC6JMEi32BBYT3H3LYu/iQ5SpdBWhBHxN7vmA/lgnBwBrer36 wVDv8A6X5NnFqLhBDoSHfeivdqvSei8dTxZFoiggkTwLPeqBZgOEXONdGiTEEkbHmTyq SEsV/5luMsxFnbUrEncKqoDArqWVceWeP/qL430/UbN0zRd2YAwhOfvKINbNl74MWFdo nFNA== 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=TEG0aX6phCBqdQm/xqfF62FVd9Ou9jjFwxo2esPZStU=; b=XkRASUAqZrz8pZH72n9x2S4/4OyoEFuQbq6gRQ9cDEQfD91BcOMsb/xDKVPrGHrlpj mfoFhpqmSOdvOWgoqAABYqWlUM9L6mtaO/ggJMqgaaaAp63wIz206W8l0GnfjNLoq7RQ j/5sfyC3ePyf+3SiX8ZjoDDkfaz09/seR6j90WYPwJG+yZpH+ogpY9rCjyvX4rdEhSQG cxzMhVrhqW/ayWD+wyaIPPqwsWNCxTqYK8ygqPO+Kot+0lFeaXpfgCLYTuOF35EE9cRp aUo/YKF4zgmAEGqOU32XWn+UbzE0ONg0n/Nd5ZAuFKAyop5NDz/pMrqnTOo3WgUJnGTx 3iew== X-Gm-Message-State: ALyK8tJndUWLg87Cjlp2Noapow4PQ1FK4/BUhSkHQFts3xbpBfqdJ9YLenbfQnUY9sDtiQ== X-Received: by 10.107.152.149 with SMTP id a143mr2771540ioe.14.1468340672780; Tue, 12 Jul 2016 09:24:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.176.76 with SMTP id z73ls696099ioe.15.gmail; Tue, 12 Jul 2016 09:24:31 -0700 (PDT) X-Received: by 10.36.123.145 with SMTP id q139mr1187482itc.7.1468340671511; Tue, 12 Jul 2016 09:24:31 -0700 (PDT) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:26813 Archived-At: ------=_Part_273_1952398638.1468340670505 Content-Type: multipart/alternative; boundary="----=_Part_274_15922509.1468340670506" ------=_Part_274_15922509.1468340670506 Content-Type: text/plain; charset=UTF-8 I also wanted this for const_cast as it can deduce what to cast to from the _argument_ and does not have to look at the possible uses of the returned value as the other casts would have to, creating a lot of awkward special rules. This is for instance useful when const_cast is used to avoid duplicating methods that do the same in a const and non-const version, such as a container operator[]. In particular with complicated template type names it can becomde rather boring, as in this example from the other day: return const_cast&>(*this)(ixes...); But this can be implemented as a library function, which solves most of the problem: template T* ConstCast(const T* src) { return const_cast(src ); } template T& ConstCast(const T& src) { return const_cast(src ); } So unless someone sees a need to standardize this function I would argue that this can be solved as needed in specific code bases. Den tisdag 5 juli 2016 kl. 18:12:06 UTC+2 skrev Jonathan Coe: > > > > > On 5 Jul 2016, at 16:57, Jim Porter > > wrote: > > > >> On 7/5/2016 10:07 AM, Nicol Bolas wrote: > >> Indeed, this is a good reason to /not/ make such casts easier to type. > >> If you're using casts so frequently that you need a language change to > >> avoid lots of repetition, then I'd say that your code is doing > something > >> wrong. > > > > Agreed. I seem to recall a (possibly apocryphal) explanation that the > C++ cast functions were verbose *because* they should be avoided unless > absolutely necessary; the verbosity thus serves as a warning to the > developer to rethink things. > > > > static_cast is an occasional exception to this rule as it can trigger > user-defined conversions. Always seems a bit awkward to me. > > > - Jim > > > > > > -- > > 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-proposal...@isocpp.org . > > To post to this group, send email to std-pr...@isocpp.org . > > > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nlgled%24jdo%241%40ger.gmane.org. > > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe93ce3f-5a6a-46dd-808e-d10ec60fb111%40isocpp.org. ------=_Part_274_15922509.1468340670506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also wanted this for const_cast as it can deduce what to= cast to from the _argument_ and does not have to look at the possible uses= of the returned value as the other casts would have to, creating a lot of = awkward special rules. This is for instance useful when const_cast is used = to avoid duplicating methods that do the same in a const and non-const vers= ion, such as a container operator[]. In particular with complicated templat= e type names it can becomde rather boring, as in this example from the othe= r day:

=C2=A0return const_cast<matrix_view_base<T, Ss..= ..>&>(*this= )(ixes...);



But this can be implemented as a lib= rary function, which solves most of the problem:

template<typename T> T<= /span>* ConstCast(const T* src) {= return const_cast<T*>(src); }
template<typename T> T& ConstCast(const T&= src) { return const_cast<T&>(src); }


So= unless someone sees a need to standardize this function I would argue that= this can be solved as needed in specific code bases.

<= br>Den tisdag 5 juli 2016 kl. 18:12:06 UTC+2 skrev Jonathan Coe:

> On 5 Jul 2016, at 16:57, Jim Porter <jvp...@g.rit.edu> wrote:
>=20
>> On 7/5/2016 10:07 AM, Nicol Bolas wrote:
>> Indeed, this is a good reason to /not/ make such casts easier = to type.
>> If you're using casts so frequently that you need a langua= ge change to
>> avoid lots of repetition, then I'd say that your code is d= oing something
>> wrong.
>=20
> Agreed. I seem to recall a (possibly apocryphal) explanation that = the C++ cast functions were verbose *because* they should be avoided unless= absolutely necessary; the verbosity thus serves as a warning to the develo= per to rethink things.
>=20

static_cast is an occasional exception to this rule as it can trigger u= ser-defined conversions. Always seems a bit awkward to me.

> - Jim
>=20
>=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 email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/ms= gid/std-proposals/nlgled%24jdo%241%40ger.gmane.org.

--
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/fe93ce3f-5a6a-46dd-808e-d10ec60fb111= %40isocpp.org.
------=_Part_274_15922509.1468340670506-- ------=_Part_273_1952398638.1468340670505-- .