220 20169 <05923671-6c37-4f99-a677-948fdd77e1dc@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Inline Classes (was "Properties" support in C++) Date: Mon, 31 Aug 2015 13:42:39 -0700 (PDT) Lines: 158 Approved: news@gmane.org Message-ID: <05923671-6c37-4f99-a677-948fdd77e1dc@isocpp.org> References: <6882b7df-80e2-40e7-960a-b39b11af2af1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1652_849393318.1441053759923" X-Trace: ger.gmane.org 1441053767 12908 80.91.229.3 (31 Aug 2015 20:42:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Aug 2015 20:42:47 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQPYSKXQKGQEDSN4NNA@isocpp.org Mon Aug 31 22:42:45 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWVuc-0003GG-9u for gclcip-std-proposals@m.gmane.org; Mon, 31 Aug 2015 22:42:42 +0200 Original-Received: by igui7 with SMTP id i7sf214902399igu.2 for ; Mon, 31 Aug 2015 13:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type: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=Aio9duwfP9xxWZ8mthje1AernXt0EsV1tXMJJgypxjw=; b=ig+YoOJHizSuoc+SA/seqAQ9VkdHSNoAzIwt1JzekFRLJR7f16o5o79EK6bRrKfb/V kZTM4Zz1rKooOyuVzckSO1v8QsZPKui/uYj9tf3+gm3ZmOvRlJw8LNuoQ53i0WsZSXjO 0zJjULZfz/LVHz1ZvbvXZgAfHCrwWqg3dqHZFr64S7qi6gGTwR15pb2QUwBsK4Pia1g6 cf7Eflun3+ftgSQfnC1cWQ5VEEYD5LgQcbxonrvGjl3k29KhH4QPe2t7ddZ3FaRZcmSV LiZfoIRHa5e4MYWpRChChujyBvlz0PIZ0o3jEel3mI7WjV42KvK7wWOGmfLSdzQjEh0O 4MRw== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type: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=Aio9duwfP9xxWZ8mthje1AernXt0EsV1tXMJJgypxjw=; b=G+OU5fmOjr12LJ6qx+FuK03Ts/b5pY/5wgtP6EiMDoTFQ+OwytzWPz1nq1ITWYRvoZ 8EULnKfDTM96owa4wQDRxFmkmkXHHsCe0GCfpfiW4r/bch3AjysOH75Q4vd5dVq1Ihye FoSCZgumK6V5khfnAXKSWx8DUqno8tlzsxazib+/3pHvTMZEy744AgdNFhoW0SdZU5UM w3FVk4Y27Nf4KHy28ZjsMGhnQ+CcAlAGin4HUP8zVJrH1qjFgQaZCA0++e107R4R19po QZYyrhG8+DcGB2qaJU8Ko3EOlW/WAVvvtr5gj4PDEQcrM5JiyYWZ/i+CdOeFrouhgiTF jEVQ== X-Gm-Message-State: ALoCoQnBi9eR9DG7gkPSLF+//JjBXbeipF1CMpVWuOS1/N0igaCRUMyH/WTW9MXh0hipSmsYtxdx X-Received: by 10.182.79.165 with SMTP id k5mr28452101obx.38.1441053761754; Mon, 31 Aug 2015 13:42:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.45.5 with SMTP id i5ls943659igm.3.gmail; Mon, 31 Aug 2015 13:42:41 -0700 (PDT) X-Received: by 10.50.110.1 with SMTP id hw1mr27240igb.0.1441053761075; Mon, 31 Aug 2015 13:42:41 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:20169 Archived-At: ------=_Part_1652_849393318.1441053759923 Content-Type: multipart/alternative; boundary="----=_Part_1653_497344196.1441053759923" ------=_Part_1653_497344196.1441053759923 Content-Type: text/plain; charset=UTF-8 On Monday, August 31, 2015 at 2:54:18 PM UTC-4, Matthew Woehlke wrote: > > (Start of original thread: > http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/20049) > > On 2015-08-30 19:05, Nicol Bolas wrote: > > One of the principle failings of all properties-through-objects classes > in > > C++ is that the property is an object and must obey the rules of C++ > > objects. Like taking up space in the class that contains them. > > > > Inline classes are defined to take up no space if they contain no > members. > > This was explicitly stated in the initial idea for them. > > Wrong: > > > On 2015-08-26 13:54, Matthew Woehlke wrote: > >> An inline class [...] has no storage > > I didn't said they "take up no space /if they contain no members/" > (emphasis added). I said they take up no space, *period*. > Either way you say it, it leads to one fact: The language must define the possibility of a member object that has no space. This is not a possibility that existed in C++ before, so inline classes must introduce that concept in order for them to work. It has to work through all of the problems surrounding allowing objects in other objects to take up no space. And if you're going to go through the trouble of defining the concept, I see no reason not to extend it to more arbitrary classes. It's the same amount of work either way. It's just that, if its a separate construct, then it can be *more* useful, since it's not bound to the limitations of inline classes. > So talking about how to allow empty types to take up no space in > > other types is part and parcel of that. Especially if it can be spun > > off into its own feature (which is much more likely to pass). > > You haven't explained why inline classes aren't usable for these other > purposes. > Because inline classes are *explicitly bound* to the classes that they are nested within. And I quote (emphasis added): > An inline class is a special case of a *nested class-type* which itself has no storage, and for which "this" refers to the parent class which must contain the inline class as a member. If I just want a freestanding class that will take up no room, regardless of which class it is used within, I can't do that with inline classes. Since it's not a nested class. -- --- 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/. ------=_Part_1653_497344196.1441053759923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, August 31, 2015 at 2:54:18 PM UTC-4, Matthew Woehlke wro= te:
(Start of original thread:
http://permalink.gmane.or= g/gmane.comp.lang.c++.isocpp.proposals/20049)

On 2015-08-30 19:05, Nicol Bolas wrote:
> One of the principle failings of all properties-through-objects cl= asses in=20
> C++ is that the property is an object and must obey the rules of C= ++=20
> objects. Like taking up space in the class that contains them.
>=20
> Inline classes are defined to take up no space if they contain no = members.=20
> This was explicitly stated in the initial idea for them.

Wrong:

> On 2015-08-26 13:54, Matthew Woehlke wrote:
>> An inline class [...] has no storage

I didn't said they "take up no space /if they contain no membe= rs/"
(emphasis added). I said they take up no space, *period*.

Either way you say it, it leads to one fact:

The languag= e must define the possibility of a member object that has no space. This is= not a possibility that existed in C++ before, so inline classes must intro= duce that concept in order for them to work. It has to work through all of = the problems surrounding allowing objects in other objects to take up no sp= ace.

And if you're going to go through the trouble of defining t= he concept, I see no reason not to extend it to more arbitrary classes.
=
It's the same amount of work either way. It's just that, if its= a separate construct, then it can be more useful, since it's no= t bound to the limitations of inline classes.

> So talking about how to allow empty types to take up no space in=20
> other types is part and parcel of that. Especially if it can be sp= un
> off into its own feature (which is much more likely to pass).

You haven't explained why inline classes aren't usable for thes= e other
purposes.

Because inline classes are explic= itly bound to the classes that they are nested within. And I quote (emp= hasis added):

> An inline class is a special case of a nested = class-type which itself has no storage, and for which "this" = refers to the parent class which must contain the inline class as a member.=

If I just want a freestanding class that will take up no room, rega= rdless of which class it is used within, I can't do that with inline cl= asses. Since it's not a nested class.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1653_497344196.1441053759923-- ------=_Part_1652_849393318.1441053759923-- .