------=_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

<div dir=3D"ltr">First, bikeshedding: if it&#39;s important enough of a fea=
ture to be a brand new construct, distinct from classes, templates, objects=
, and other things, then it&#39;s important enough to have its own <i>keywo=
rd</i>. So let&#39;s not further overburden `using` and `inline` when we ar=
e really talking about something that has nothing to do with <i>either</i>.=
<br><br>Second, if you are aware that this construct is commonly called a &=
quot;mixin&quot;, why are you making up a new word for it?<br><br>Third, yo=
u need to explain why the common mechanisms for implementing mixins are suf=
ficiently inadequate that we explicitly <i>need</i> a brand new construct. =
I actually know a couple of answers for this. But if this is going to progr=
ess from &quot;random idea&quot; into a proposal, then you need to explain =
why the CRTP is inadequate for handling this.<br><br>Fourth, what about mix=
in composition? That is, you implement one mixin by including another. And =
what about <i>private</i> composition? That is, your mixin incorporates ano=
ther mixin, but you <i>don&#39;t</i> want someone else who uses your mixin =
to expose the stuff you pulled in in its public interface. That&#39;s not a=
s ridiculous as it sounds; you are merely using a mixin internally, not exp=
orting it as your interface. It&#39;s no different from private inheritance=
.. Which obviously CRTP-based mixins can handle.<br><br>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&#39;re goi=
ng to add a language feature for this, then it had better be able to handle=
 that.<br><br>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?<br><br>I have all of these questions because=
 I&#39;ve looked closely at the mixin problem before. And these are <i>very=
 much</i> non-trivial questions to answer, but they are absolutely crucial =
for getting somewhere with this.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/54de6084-e941-4123-9c57-4a3d0775cf79%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/54de6084-e941-4123-9c57-4a3d0775cf79=
%40isocpp.org</a>.<br />

------=_Part_2345_938169155.1486507171409--

------=_Part_2344_1744748366.1486507171409--

.