220 39773 <62ee3367-579f-411f-a80e-372aad4d3f5e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts about relocation Date: Tue, 14 Aug 2018 02:09:14 -0700 (PDT) Lines: 142 Approved: news@gmane.org Message-ID: <62ee3367-579f-411f-a80e-372aad4d3f5e@isocpp.org> References: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> <80de22c4-3a25-4b12-b7b3-8338ee3a8247@isocpp.org> <6fda45cd-1409-4247-97bf-f36ee40ee9b2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1722_807094698.1534237754566" X-Trace: blaine.gmane.org 1534237630 28602 195.159.176.226 (14 Aug 2018 09:07:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2018 09:07:10 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBO5YZLNQKGQE6GFIZEA@isocpp.org Tue Aug 14 11:07:06 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fpVIA-0007Ju-0M for gclcip-std-proposals@m.gmane.org; Tue, 14 Aug 2018 11:07:06 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id z200-v6sf25225706ywd.22 for ; Tue, 14 Aug 2018 02:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=pm5s1En3rEH8sSeOhYmaRhPbKDAtvLoLutoEtJ6SPCs=; b=oYQzlYpvDvArXkan93KqfLPU1+DC2oFCUeiYYedzEUvvfS62xcJnFUOYlitiJ18T9C 28H80y2yO+50JJQhchjBYDLe1Y1HNDnll/g3ZsT39YwFIKCvVB7RifWkEUmTt36YdZXx gJNxTVsg12rTQRls/f62+Xc/jL5moKaHeaWmsFjrtO1N3awD/d1rGTpQ20Noi7s574xY 3Gu/oGmeD0MrfiTKVudRCFWIq3mBJzRCdxaYPiN6tUwGeCkC1Jgop4sP29vkGfwB7nfd Po0mNwZrt0IUwYHdv5FTMyVevlel6droGq1fVuTsVJVjT+EKVltP3Ct0Hm3aRyTFhcxb G66g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=pm5s1En3rEH8sSeOhYmaRhPbKDAtvLoLutoEtJ6SPCs=; b=aXhdtF5mb6xd1IC9EbufDzSVBZ8GGAM3yAInQMqc+3nGUoYwdQlBIjHBInw8/oYASQ mCha+6ckBYcIODPrlHpaq2zpyv2ewoMZTK3wnbs99d+B4pgc8gCfKRUKLBUhLJHtHwBw yPOovPNGo4n8zMuleYEhuKv5aP2ia6jBuN5CcPmKJsSS0+jBqgRqPCXeEDM5WJBBpBKD v1c1ef1Q1zTO+pNgPS8mjnZCqk/kk0HSxsiI12AIc9CAb7aVUXIUttKdjPPaIxLbS1Y7 YJnAu5tFixMpeg1bpdwCoHrO0VJRhmgdcttetluUhriN06Y2uDug/rUGwSxGQJ5v1BeT 9M1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc: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=pm5s1En3rEH8sSeOhYmaRhPbKDAtvLoLutoEtJ6SPCs=; b=dRoEPKvXSSQOwOFZoWT6DTbW7jtdE+Won8nQkq9VAsEHkUFjgGRoxAhIus/ziKvo4X 6wBolwAhJ1FXJ7mUr+dcyQBe7USvLLAs10pVrgB+0B0HKQD8wEDIA3MnJRsN/QkkauTy fcaam0uGGXr/h8UCHyLdw8eEwYhs/6P7HcUm+anOkGai8lua5JvXIY56Nc+Vnb4jVO9k ZnnGZ5rTuZucGJaqkZnrEhTGwIkdvaqqwAzHYx5retZ8PZtqzuSBdRWsfwjplF+7bQiK JWTcgr38DshY+DKfi1lrmIwcfLP5zXt0mHjXpaUb1Hk2AydCHiTF6+GdEgLuK8rZgu/V SltQ== X-Gm-Message-State: AOUpUlExy5PD3Mr+1SrphPQVqlgtXRNRpIKmy0VD2UFJ8GW5YoX3RKbz opfT2Xn8nz4wp2bio8wChVZGJA== X-Google-Smtp-Source: AA+uWPwL1wIdOocQDG14U3mqEkXBWHyNi/BlL+nMMvFp5PhuMc6/ajQMhYgSHePaiLKsos++7gH0DQ== X-Received: by 2002:a25:46c6:: with SMTP id t189-v6mr5776553yba.77.1534237756366; Tue, 14 Aug 2018 02:09:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:11d3:: with SMTP id 202-v6ls3488584ywr.9.gmail; Tue, 14 Aug 2018 02:09:15 -0700 (PDT) X-Received: by 2002:a81:7dd6:: with SMTP id y205-v6mr449539ywc.1.1534237755044; Tue, 14 Aug 2018 02:09:15 -0700 (PDT) In-Reply-To: <6fda45cd-1409-4247-97bf-f36ee40ee9b2@isocpp.org> X-Original-Sender: florian.csdt@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:39773 Archived-At: ------=_Part_1722_807094698.1534237754566 Content-Type: multipart/alternative; boundary="----=_Part_1723_582983710.1534237754566" ------=_Part_1723_582983710.1534237754566 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mardi 14 ao=C3=BBt 2018 10:54:53 UTC+2, Niall Douglas a =C3=A9crit : > > That's exactly why I built my proposal from scratch to define relocation,= =20 >> and make it part of the language as core feature, and not a patchwork ab= ove=20 >> the rest. >> It's a bottom-up approach: define the base bricks, and use them to build= =20 >> the language. >> It's most likely not enough for you, but at least I tried. >> >> My approach tries to limit as much as possible those UB. But as soon as= =20 >> IPC kicks in, I have no choice (I'm not expert enough to propose somethi= ng=20 >> useful about IPC). >> > > You've completely missed the point. > Out of any context, your point was difficult to guess. > We're all inventing a vocabulary here. It's not productive. We need to=20 > stop doing that. > > For me, the only way to standardize a term is to standardize the feature=20 related to the term. Otherwise, the term might end up with a definition off= =20 compared to what the feature will need. And the only way I see to do that, is to invent some vocabulary terms for= =20 each proposal. The goal is then to converge on the term used and its definition. But than= =20 cannot be done upfront! =20 > Somebody needs to go study a real compiler and generate a vocabulary whic= h=20 > that real compiler itself uses internally. Otherwise we are wasting effo= rt. > I'm speculating here, but I think that compiler devs don't agree on most of= =20 those terms neither. Scientific papers might be a good source for that (because of the=20 scientific consensus), but I doubt there are many papers on this particular= =20 subject. =20 > > Niall > --=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/62ee3367-579f-411f-a80e-372aad4d3f5e%40isocpp.or= g. ------=_Part_1723_582983710.1534237754566 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le mardi 14 ao=C3=BBt 2018 10:54:53 UTC+2, Niall D= ouglas a =C3=A9crit=C2=A0:
= That's exactly why I built my proposal from scratch to define relocatio= n, and make it part of the language as core feature, and not a patchwork ab= ove the rest.
It's a bottom-up approach: define the base bric= ks, and use them to build the language.
It's most likely = not enough for you, but at least I tried.

My appro= ach tries to limit as much as possible those UB. But as soon as IPC kicks i= n, I have no choice (I'm not expert enough to propose something useful = about IPC).

You've complete= ly missed the point.

Out of any= context, your point was difficult to guess.


We're all inventing a vocabulary here. It's not productive. We nee= d to stop doing that.


For me, the only way to standardize a term is to standardize the feat= ure related to the term. Otherwise, the term might end up with a definition= off compared to what the feature will need.
And the only way I s= ee to do that, is to invent some vocabulary terms for each proposal.
<= div>The goal is then to converge on the term used and its definition. But t= han cannot be done upfront!
=C2=A0
Somebody needs to = go study a real compiler and generate a vocabulary which that real compiler= itself uses internally.=C2=A0 Otherwise we are wasting effort.
=

I'm speculating here, but I think= that compiler devs don't agree on most of those terms neither.
Scientific papers might be a good source for that (because of the scient= ific consensus), but I doubt there are many papers on this particular subje= ct.
=C2=A0

Niall

--
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/62ee3367-579f-411f-a80e-372aad4d3f5e= %40isocpp.org.
------=_Part_1723_582983710.1534237754566-- ------=_Part_1722_807094698.1534237754566-- .