220 5939 article Path: news.gmane.org!not-for-mail From: cornedbee@google.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Mixins for C++ Date: Wed, 28 Aug 2013 05:59:47 -0700 (PDT) Lines: 138 Approved: news@gmane.org Message-ID: References: <787081f7-fb40-4507-907d-259318ef2000@isocpp.org> <1c80b902-4e65-4f4b-a5d7-8953dbf6df05@isocpp.org> <7035c144-8350-40d4-bf23-03ab7aa7fe53@isocpp.org> <816418a5-e8cd-4a26-ba9a-81ab55277748@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_57_24001336.1377694787741" X-Trace: ger.gmane.org 1377694787 10010 80.91.229.3 (28 Aug 2013 12:59:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Aug 2013 12:59:47 +0000 (UTC) Cc: cornedbee@google.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD43DGWT5IFRBRHI66IAKGQESR5SUJI@isocpp.org Wed Aug 28 14:59:50 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VEfLh-0005RW-RY for gclcip-std-proposals@m.gmane.org; Wed, 28 Aug 2013 14:59:50 +0200 Original-Received: by mail-ye0-f198.google.com with SMTP id m12sf6334734yen.5 for ; Wed, 28 Aug 2013 05:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; 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:content-type; bh=NEqP+I3DJ7M78k0aYonKvlGSnfO3ualhEtamu0qWbnE=; b=R0Szds/82LeVBnfZQ1Rwig3ri7JzSfUK/HmwSGOPYWx0ELuNs25kvIWlnb09GaSBK7 OvNGJMj02b3Z4QHxXOifzSaVrmxZn8j9jwXVuSBs07I1d0URsC5nOr5xiF6iDq5BdVHT 6V5sqkm6kC3HRC2TNHkzKA3XXmN32YXu9xOhTj3azHprLMR18qNFY8fadOufAIMCI2it D0MrUqmdjBof2CF4KLebWve5VD57M6TxJR8QEXvEF24zMg6noBY1AtExR2/FuTNPAjwJ BKQ+BYlmHBoa2gqQKViUhPedIDWT1WoT3c7Uhj47SzHo9lgjxwUIRoP1rm9lMwzRz8+5 hpmQ== X-Received: by 10.236.31.2 with SMTP id l2mr9846962yha.36.1377694788963; Wed, 28 Aug 2013 05:59:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.1.227 with SMTP id 3ls344848qep.84.gmail; Wed, 28 Aug 2013 05:59:48 -0700 (PDT) X-Received: by 10.49.98.162 with SMTP id ej2mr30891qeb.10.1377694788354; Wed, 28 Aug 2013 05:59:48 -0700 (PDT) In-Reply-To: X-Original-Sender: cornedbee@google.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:5939 Archived-At: ------=_Part_57_24001336.1377694787741 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, August 28, 2013 2:44:01 PM UTC+2, R=F3bert D=E1vid wrote: > > Macros are a hack. Every use of macros indicates a place where the core= =20 >> language is lacking. >> >> > Macros are part of the language. It will not go away. We have to live wit= h=20 > this fact. > But that doesn't mean we have to celebrate it. Inline functions, real=20 constants, templates, now constexpr functions, are all replacing uses of=20 macros. Attributes replace pragmas to some extent. Modules are in=20 development to subsume/replace/obsolete includes. We cannot ever get rid of= =20 the preprocessor, but we want to relegate it to exotic uses and backward=20 compatibility. If you don't think this is a good goal to have, you are of course entitled= =20 to that opinion, but I think you won't find many like-minded people in the= =20 C++ community, much less the standard committee. =20 > But with *improvements* (sorry, but everyone seem to miss that this is my= =20 > point) it could also work in the place of mixins. > No, I get it. But the preprocessor is fundamentally, irrevocably at a=20 completely different level than the rest of the language - it has its own= =20 rules about what a token is! There's just no place to *start* when you=20 suggest improvements to the preprocessor to make it a viable way of=20 routinely doing things. =20 > Same way as MI / CRTP could. > Awaiting your reply to my earlier post. =20 > Either way, with "small" standard changes you could have what you need=20 > (with different syntax), and the language doesn't need an extra ~hundred= =20 > pages describing every single current feature's interaction with the new= =20 > mixin feature. > I don't know why you put "small" in quotes. Maybe because you yourself=20 don't believe they are actually small changes? To achieve what I want, you= =20 would have to mangle the current concept of inheritance beyond recognition,= =20 and if you do that, what is the point of using inheritance? =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 e= mail 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-proposa= ls/. ------=_Part_57_24001336.1377694787741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, August 28, 2013 2:44:01 PM UTC+2, R=F3bert D= =E1vid wrote:

Macro= s are a hack. Every use of macros indicates a place where the core language= is lacking.


Macros are par= t of the language. It will not go away. We have to live with this fact.
=

But that doesn't mean we have = to celebrate it. Inline functions, real constants, templates, now constexpr= functions, are all replacing uses of macros. Attributes replace pragmas to= some extent. Modules are in development to subsume/replace/obsolete includ= es. We cannot ever get rid of the preprocessor, but we want to relegate it = to exotic uses and backward compatibility.
If you don't think thi= s is a good goal to have, you are of course entitled to that opinion, but I= think you won't find many like-minded people in the C++ community, much le= ss the standard committee.
 
But with <= b>improvements (sorry, but everyone seem to miss that this i= s my point) it could also work in the place of mixins.

No, I get it. But the preprocessor is fundamentally= , irrevocably at a completely different level than the rest of the language= - it has its own rules about what a token is! There's just no place to *st= art* when you suggest improvements to the preprocessor to make it a viable = way of routinely doing things.
 
Same way as MI / CRTP could.<= /div>

Awaiting your reply to my earli= er post.
 
Either way, with "small" standard changes you could= have what you need (with different syntax), and the language doesn't need = an extra ~hundred pages describing every single current feature's interacti= on with the new mixin feature.

<= div>I don't know why you put "small" in quotes. Maybe because you yourself = don't believe they are actually small changes? To achieve what I want, you = would have to mangle the current concept of inheritance beyond recognition,= and if you do that, what is the point of using inheritance?
&nbs= p;

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