220 37170 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: pseudo constness Date: Thu, 1 Mar 2018 19:46:12 +0000 Lines: 208 Approved: news@gmane.org Message-ID: References: <1519283315.58210.23.camel@gmail.com> <0a7e7e42-aa28-4632-8e66-56b0633755ba@isocpp.org> <27b5c95c-5b44-4089-bb14-b2d1b806093b@isocpp.org> <4b81b3b8-5def-4003-b073-89af676e837a@isocpp.org> <34d1dde0-b9fd-4565-8ebe-a1b1936ab96d@isocpp.org> <5262af56-c631-4c62-954c-1a2b90904319@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e08232cf4e409ee05665f1dbb" X-Trace: blaine.gmane.org 1519933473 21561 195.159.176.226 (1 Mar 2018 19:44:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2018 19:44:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRYVJ6TVYBRBGVR4HKAKGQE32RJ72A@isocpp.org Thu Mar 01 20:44:29 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f197.google.com ([209.85.128.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erU7x-0004zM-8P for gclcip-std-proposals@m.gmane.org; Thu, 01 Mar 2018 20:44:29 +0100 Original-Received: by mail-wr0-f197.google.com with SMTP id x97sf4858499wrb.3 for ; Thu, 01 Mar 2018 11:46:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1519933596; cv=pass; d=google.com; s=arc-20160816; b=rQu99srV1W7gs/Lcy+UQhkIV5DM/JITlE2Vet9tnOMUxmqc0UuUznyJdb6AgnauIzf nLhvLKosBOy3P9ynXNtGOPkumViCkCOvHeuIlHrZiReIUBN7EILnq0Jc7f054pcOPV4r KPsXeq7y2Ehf3W9YrXgqJkMG7w7oPZ5IMMuFSq7up+vCoD04dgbCPSE/AJ7Nx7dwUQGY xvyc4jf7rFtifaEvAjMqRzMXkhENWiorXrHJj6NwPuuOIce53PnhJovltKNGAirGbJKC 4cibypq/b2t8cusVQMtFDrBzbz5KX2uu1p2V7TbsTkZPzeukFEdwpZbQZIdIccoNtlO4 sQcw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=7Z5gIgmbhsawYQCtxTfxLbYC9GVfpPAqZm1eTU/Y+TU=; b=L1/dLKHmAXajVBvbhZu7jcxLp2cyoCUy2K8+eoROtlmy/vGJgUKy549QMpzXEvS/yr xaTaidumOrvqnHhmW/zbszBKyb1/OpnIPY88jfDli14qHbrTmLqVY9CHlWGJ9PKrN6DA BeA4rQzXNudC2+5RLK56fVSdBz9SYITcLN7l2DhgPNdsGGoex7IRaKyCPNl6HFpbc+w9 eksuTONL1fqRmJO8sZXd2BJTc9an5b14j46jOmrgMqVCaRxnUc1EycxWHu3dOXJeSRvU AzV1LawZjOnuvrAyIy1pn4jIrbLwy40tIf3flJaKKO89kOEJhqQqIuOaIYkVW49+OCur ojUg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ww61OdGM; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=7Z5gIgmbhsawYQCtxTfxLbYC9GVfpPAqZm1eTU/Y+TU=; b=U5khVt0qcA4cAATOSgmaDj9Aau+P/c8cVZK6ZlxNgmslAsEi3LPM3q61wB4fWqTX5v mCeg5QIzF+p9zA5MlFqxD1wY3VIs9zbQafzEsHiP7qzXjoQ67qncngETDNLwbQLzRPqP HcOFsoYX9qbIbE0mb6j5Jk2wF6UveDNyXYHH/OtSjj3wr6Ci1lVKDRyzwihngUa06qwL AXJV7Wm4OA2Ai4HPpaJH/B/z9FTKbegvMFdH/Dm++FPrnQzt6gRnG4OPWjXvOPzMD9RB bPWR3ISD5hs0vQfTX8Kbn8uf2sHQmaYLID2YxecWfEScie8vLUBw9vxgaczD5bQFZDYr 5o4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7Z5gIgmbhsawYQCtxTfxLbYC9GVfpPAqZm1eTU/Y+TU=; b=CVQcN2gqyIlF1F4C/Ec2hQM1y3sxtKoORU8GBbgdaQxy9tHUfbUdUmrlxN7xs8xuiT PuAAZi5ioJSDqdq8jQuBLrprORCLYNg5Dp/1pQxz9F5vnreW1gHBEEgluZHEy8zby1T7 Rfg1OFuouErigwHEF3po6nqC1yx/UGVuTGounaFUnCgB2Bbe/csiv5C50Gc23lRS6PUF sTXOPRY1EUqx5anCzpdKVAp27EYn1JKbrH4w3fiq2ZsXEzbJklFIRngvbWH6RL10ZQr0 FxXJ+dG2DwYu8sBt3ZCYml3Ylxnkooq791rRl9UswPu8zF6V6XReDmKffQNCv7xqzBcS N9Pg== X-Gm-Message-State: APf1xPBkZkLuisPpyDqEKE40/i2xH6KsIa8I+OK89WU3Q2N8ApmsZ3IJ sgPe4WZVXT5CEgxSsJGGVYrXzQ== X-Google-Smtp-Source: AG47ELvwC5y5C1s0sHKb7SAXPvXxgPnNKhTGh/5QXZh2Qas8k20x9kQmQpOt6r0zYK4EOJpZnxpvfw== X-Received: by 10.28.15.140 with SMTP id 134mr349520wmp.25.1519933595945; Thu, 01 Mar 2018 11:46:35 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.142.56 with SMTP id n53ls2224358wrb.12.gmail; Thu, 01 Mar 2018 11:46:33 -0800 (PST) X-Received: by 10.223.200.144 with SMTP id k16mr3020854wrh.282.1519933593859; Thu, 01 Mar 2018 11:46:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519933593; cv=none; d=google.com; s=arc-20160816; b=ZyiqbC4slp4Xj9LC92vzKuExKHm08/WSZi8QxpZTFMfM6yrwAvV1F2O+iSjU/y1ifs KPyWy9/9PwCYC73rSW8AFwtGWo35ZDlmIloVMj0ye43YBpadtDSFnSdeW7cLdYCQNX08 VXnyeUzG/a8B1JBJRX3yk0ZJxtJS1IQfj7d9OOdZi0IwqQojQhGIOnr4bNjqqk+pXmfE pFmXG5BN0ud1+ueR4f7aUcm+cVQkrgkg8Z87Yi1mDFGNc8FoUjOACGCQQ6GDHlmtevqF co3Ww2OwhV2Mlud2Mw95nP0VPawzpFFALbBq0qxEs5+NjJXk8GOchNmhdNvx3xID7Cib 6Bmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=qKi0abqFQ4QtkEdiWGnhlV/CvVgaVoS9dn+jpXDiVMM=; b=FVrfx2n77avCOOA14oZ8uoDD26Sl0R5rvwzgRlrU0Vt/AiLqk+CyR8PbqdJMmlvM0p 9Jjpd/tDTzxXEG7szmgZkuG+EOPpDQDibIG74NQvceUq7cDGcuEkPnNd0/7Ack9LTW98 /GyRiuBI6eOKym8Plr6K500dlAEvZpL0k6GVgX6vwRlSRya+vQZ5exwTCFCl4yZ2wx4C cLT3GMoPXeyDvvQsZb13vsdc93u+GOD1bGmbu7UefQXljFmIbfa4bMMrAfebpb43t3j9 ZkjxX0kCKSBC2iDnZf3vSuGoMTE3wiYlYqI+Y/75h8ewbZsxsIiO5sqS+/eTLm2G/sXL uDqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ww61OdGM; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id s79sor2466407wrc.46.2018.03.01.11.46.33 for (Google Transport Security); Thu, 01 Mar 2018 11:46:33 -0800 (PST) Received-SPF: pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.223.183.75 with SMTP id n11mr2836370wre.162.1519933592961; Thu, 01 Mar 2018 11:46:32 -0800 (PST) Original-Received: by 10.223.183.31 with HTTP; Thu, 1 Mar 2018 11:46:12 -0800 (PST) In-Reply-To: X-Original-Sender: gasper.azman@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ww61OdGM; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.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:37170 Archived-At: --089e08232cf4e409ee05665f1dbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So the main issue is that some method of avoiding UB is needed but the method needs to advertise const. Let's imagine for a second that we now have three layers in the type system - immutable (writing to memory is always UB), const (like now sans UB so casts permitted, can't be in ROM) and regular mutable. Now we are forcing API designers to choose which type of const/immutable reference they will accept, since immutable objects cannot (ever!) downcast to const. Option a) almost-always-immutable&: This one is very much like the current const& thing. Unfortunately this means that things that are const& are basically useless in the immutable& world, since no library actually works with them - they all want immutable& for convenience's sake so that they can be used with immutable objects. Option b) almost-always-const&: In this world, immutable objects are basically useless, since they can't be used with the majority of libraries, which really just want to say "I'm not going to mutate this" - and they don't, so could have been taking immutable= .. Option c) Everyone does their own thing This one is a mix of above, which sucks even more. All of these suck. This is why we don't have different meanings of const in the language. Introducing a third has always seemed like the cure is worse than the disease. Basically, I don't know how to do this in a way that doesn't make huge problems for library authors within the typesystem. Perhaps we could define const better, and just say that modifying objects declared const is defined behavior as long as they haven't been put into ROM. Say we introduce something like class Foo { int bar; void my_pseudoconst() const mutable { ++bar; --bar; } }; which basically says "classes that have mutable methods can't be put into ROM and have defined const-cast for this semantics". I could do with something like that. I don't see how introducing another constness category would ever work, though. G On Thu, Mar 1, 2018, 18:29 Nicol Bolas wrote: > > > On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman wr= ote: >> >> I'm not sure if I understand - is there a scenario where you would >> provide both a const and a pseudoconst method on a class? >> >> If it's just a matter of implementation, you know you can const-cast the >> this pointer into a non-const pointer so you can call mutable methods on= it? >> > > "Can" is a strong word. If the object itself was declared `const`, then > you "can" not. Or rather you "can", but any mutable calls will provoke UB= .. > > -- > 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/ebc67007-559d-424d- > aaeb-e92be7a615d7%40isocpp.org > > . > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAANG%3DkUYquvFbhyT_zen2Kda1H4R_R8_uMz422zmzEgu%= 3D97yrQ%40mail.gmail.com. --089e08232cf4e409ee05665f1dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So the main issue is that some method of= avoiding UB is needed but the method needs to advertise const.

Let's imagine for a second that we no= w have three layers in the type system - immutable (writing to memory is al= ways UB), const (like now sans UB so casts permitted, can't be in ROM) = and regular mutable.

Now= we are forcing API designers to choose which type of const/immutable refer= ence they will accept, since immutable objects cannot (ever!) downcast to c= onst.

Option a) almost-always-immutab= le&:

This one is very much like the current co= nst& thing. Unfortunately this means that things that are const& ar= e basically useless in the immutable& world, since no library actually = works with them - they all want immutable& for convenience's sake s= o that they can be used with immutable objects.

Op= tion b) almost-always-const&:

In this world, i= mmutable objects are basically useless, since they can't be used with t= he majority of libraries, which really just want to say "I'm not g= oing to mutate this" - and they don't, so could have been taking i= mmutable.

Option c) Everyone does their own thing<= /div>
This one is a mix of above, which sucks even more.

=

All of these suck. This is why we don't have = different meanings of const in the language. Introducing a third has always= seemed like the cure is worse than the disease.

<= br>

Basically, I don't know how to do this in = a way that doesn't make huge problems for library authors within the ty= pesystem. Perhaps we could define const better, and just say that modifying= objects declared const is defined behavior as long as they haven't bee= n put into ROM. Say we introduce something like

=C2=A0 i= nt bar;
=C2=A0 void my= _pseudoconst() const mutable {
=C2=A0 =C2=A0 ++bar;
=C2=A0 =C2=A0 --bar;
=C2=A0 }
};

which basically says "classes that have m= utable methods can't be put into ROM and have defined const-cast for this=C2=A0semantics". I could do with something like that. I= don't see how introducing another constness category would ever work, = though.

G
<= div>



On Thu, Mar 1, 2018, 18:29 Nicol Bolas <jmckesson@gmail.com&g= t; wrote:


= On Thursday, March 1, 2018 at 1:26:14 PM UTC-5, Ga=C5=A1per A=C5=BEman wrot= e:
I'm not sur= e if I understand - is there a scenario where you would provide both a cons= t and a pseudoconst method on a class?

If it's just a matter of implementation, you know you can con= st-cast the this pointer into a non-const pointer so you can call mutable m= ethods on it?

"Can" is a strong = word. If the object itself was declared `const`, then you "can" n= ot. Or rather you "can", but any mutable calls will provoke UB.

--
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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-= proposals/ebc67007-559d-424d-aaeb-e92be7a615d7%40isocpp.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/CAANG%3DkUYqu= vFbhyT_zen2Kda1H4R_R8_uMz422zmzEgu%3D97yrQ%40mail.gmail.com.
--089e08232cf4e409ee05665f1dbb-- .