220 30822 <54de6084-e941-4123-9c57-4a3d0775cf79@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Layers: inlining definitions (was Re: Re: Statement expressions proposal) Date: Tue, 7 Feb 2017 14:39:31 -0800 (PST) Lines: 106 Approved: news@gmane.org Message-ID: <54de6084-e941-4123-9c57-4a3d0775cf79@isocpp.org> References: <0f9df0e1-72e2-b26d-4625-a36529760d6f@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2344_1744748366.1486507171409" X-Trace: blaine.gmane.org 1486507172 28539 195.159.176.226 (7 Feb 2017 22:39:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 22:39:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJEZ5HCAKGQEL7JTUPA@isocpp.org Tue Feb 07 23:39:28 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbEQ3-00078F-DJ for gclcip-std-proposals@m.gmane.org; Tue, 07 Feb 2017 23:39:27 +0100 Original-Received: by mail-pg0-f69.google.com with SMTP id 194sf169482758pgd.7 for ; Tue, 07 Feb 2017 14:39:33 -0800 (PST) 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=8teUhlMDhfeXzfYcy9pxKLf+dbnKchpJN5P8PWjqyd8=; b=qe0BiHTb3AZVO82K41etzxXOeoGAULghMx+vd6yf65RCLd3FR39oi4Msz6aZpAnl+Y 3A1IW92Sb1lCgUpHt8u2wYRISGNfJC8JeHYY6EF+Q9/idS8jKVdoZQ4vgD68sKfo3fjt n3gZkkaKUu+cknbmfck5gZXIRZnNstiihheuP6H6VqfNmcaEr1owwmumSnlNqUSqaEO0 /cquKp6JYfom+o3fwbnedR2G1Zmugy+Ya+qqu9e5ETUqB248RSEA3dQ5K+Mt7RcmyyM/ 5zp4ZUkEj6os4zvOCA521U5A0vmxNCrLdgX3p33RKl0OtmX8oz3YbA+a7LoHuTqOwezq SvyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=8teUhlMDhfeXzfYcy9pxKLf+dbnKchpJN5P8PWjqyd8=; b=MEucmbyFnILfG+uejPrm9itZ9E/GxfdFTfaTi66eQLcdMa+SmrjzYZY7ySk0WKNSPu qXd0KBfiLEade9qoDb8P0tsCv4PAst8lD7WlOIxLq+HiJH1rdLFd7X+ZaItoIrJXplFL /Ad4xQ6tZ8s4h9H/oRsz9akX3Bw70xCBwfUUjExRUpuneum7CfGKME9//c0n2OD2Ula9 +nJCsEQQ6EM6PfM6vNQaJQSP/wOkGSP56GCbM8f1luUm/oRAIaHXFYxDo2ToODUE2hBz hqfFh2TzfaSw++mpSMhfAGyhYnu90bXQ3LprBppbTsscgb5R7tVUDlzWKS1UMfSIuqPF D6RQ== 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: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=8teUhlMDhfeXzfYcy9pxKLf+dbnKchpJN5P8PWjqyd8=; b=q5M0XB+MK8bqVqhxVFMXA4hrHsLHy2gzVPsj+Ky2NvWC7Ad2pPCer908fSfeHWoiMl Boovbq9XFMcVZ8lBx++E6BC6YKvYWf0snv0mGSYRM8xF1j84eJWOLJUR5fna6mGKtLHH WmhtH3rTndh9LukX8u7eGCxJOvCF0H1ElDxi7IRmg4lySsBfN9lRSziYAvyLmd4hOJfW X99SPJhVEB13aUctf+91Nj6Yt3iHv63DEE/vsm5ovqP5VD3BgxfrfvC7uqa8z9TFspcE Bsaq0MV0e8aAMTSYcuNoRd4v0KhdRYRBvS3tryT9tXWIU0Tps4+iBE2inwn4T4K+yDPK 4UIQ== X-Gm-Message-State: AIkVDXLXqKl4DaM7LCn3qSyhd4qTlJ6EfRsoRwuPs1WKa8vV/Xv4FzsYvxWT4Ke8oLWI4g== X-Received: by 10.99.234.5 with SMTP id c5mr4744290pgi.172.1486507172656; Tue, 07 Feb 2017 14:39:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.105 with SMTP id r38ls17431806otd.15.gmail; Tue, 07 Feb 2017 14:39:31 -0800 (PST) X-Received: by 10.157.16.48 with SMTP id h45mr1205853ote.10.1486507171914; Tue, 07 Feb 2017 14:39:31 -0800 (PST) In-Reply-To: <0f9df0e1-72e2-b26d-4625-a36529760d6f@wanadoo.fr> X-Original-Sender: jmckesson@gmail.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:30822 Archived-At: ------=_Part_2344_1744748366.1486507171409 Content-Type: multipart/alternative; boundary="----=_Part_2345_938169155.1486507171409" ------=_Part_2345_938169155.1486507171409 Content-Type: text/plain; charset=UTF-8 First, bikeshedding: if it's important enough of a feature to be a brand new construct, distinct from classes, templates, objects, and other things, then it's important enough to have its own *keyword*. So let's not further overburden `using` and `inline` when we are really talking about something that has nothing to do with *either*. Second, if you are aware that this construct is commonly called a "mixin", why are you making up a new word for it? Third, you need to explain why the common mechanisms for implementing mixins are sufficiently inadequate that we explicitly *need* a brand new construct. I actually know a couple of answers for this. But if this is going to progress from "random idea" into a proposal, then you need to explain why the CRTP is inadequate for handling this. Fourth, what about mixin composition? That is, you implement one mixin by including another. And what about *private* composition? That is, your mixin incorporates another mixin, but you *don't* want someone else who uses your mixin to expose the stuff you pulled in in its public interface. That's not as ridiculous as it sounds; you are merely using a mixin internally, not exporting it as your interface. It's no different from private inheritance. Which obviously CRTP-based mixins can handle. Fifth, with C++ programmers now being advised to not add members when not strictly necessary, how do you add non-member functions to a class with such a technique? CRTP-based mixins can do that by specialization and inheritance. If we're going to add a language feature for this, then it had better be able to handle that. Sixth, how exactly is compilation supposed to work under this model? Are mixin definitions just a bunch of tokens? Do they get instantiated like templates, filling in all of the missing pieces? How does name lookup work with regards to them? I have all of these questions because I've looked closely at the mixin problem before. And these are *very much* non-trivial questions to answer, but they are absolutely crucial for getting somewhere with this. -- 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/54de6084-e941-4123-9c57-4a3d0775cf79%40isocpp.org. ------=_Part_2345_938169155.1486507171409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, bikeshedding: if it's important enough of a fea= ture to be a brand new construct, distinct from classes, templates, objects= , and other things, then it's important enough to have its own keywo= rd. So let's not further overburden `using` and `inline` when we ar= e really talking about something that has nothing to do with either.=

Second, if you are aware that this construct is commonly called a &= quot;mixin", why are you making up a new word for it?

Third, yo= u need to explain why the common mechanisms for implementing mixins are suf= ficiently inadequate that we explicitly need a brand new construct. = I actually know a couple of answers for this. But if this is going to progr= ess from "random idea" into a proposal, then you need to explain = why the CRTP is inadequate for handling this.

Fourth, what about mix= in composition? That is, you implement one mixin by including another. And = what about private composition? That is, your mixin incorporates ano= ther mixin, but you don't want someone else who uses your mixin = to expose the stuff you pulled in in its public interface. That's not a= s ridiculous as it sounds; you are merely using a mixin internally, not exp= orting it as your interface. It's no different from private inheritance= .. Which obviously CRTP-based mixins can handle.

Fifth, with C++ prog= rammers now being advised to not add members when not strictly necessary, h= ow do you add non-member functions to a class with such a technique? CRTP-b= ased mixins can do that by specialization and inheritance. If we're goi= ng to add a language feature for this, then it had better be able to handle= that.

Sixth, how exactly is compilation supposed to work under this= model? Are mixin definitions just a bunch of tokens? Do they get instantia= ted like templates, filling in all of the missing pieces? How does name loo= kup work with regards to them?

I have all of these questions because= I've looked closely at the mixin problem before. And these are very= much non-trivial questions to answer, but they are absolutely crucial = for getting somewhere with this.

--
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/54de6084-e941-4123-9c57-4a3d0775cf79= %40isocpp.org.
------=_Part_2345_938169155.1486507171409-- ------=_Part_2344_1744748366.1486507171409-- .