Topic: algebraic data types
Author: walter1234 <walter2bz@gmail.com>
Date: Thu, 12 Jun 2014 02:23:33 -0700 (PDT)
Raw View
------=_Part_98_32578817.1402565013879
Content-Type: text/plain; charset=UTF-8
Having been looking into Rust, one of the best bits is its use of
enum/match to implement tagged-unions. (of course this has supposedly been
around in functional languages for a lot longer)
Are there any proposals to add features that would streamline the use of
tagged-unions in C++? .. perhaps some sort of 'enum union' declaration,
with a corresponding equivalent to rusts' match to quickly access variants
Of course C and C++ have always been able to represent this sort of thing,
just in a more manual way (more fine grain control, but more verbose and
error-prone too)
maybe there are better ways in which the vtable information could be
leveraged to do a similar job, if there's concern that its just too much
complexity alongside everything C++ already does.
--
---
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_98_32578817.1402565013879
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Having been looking into Rust, one of the best bits is its=
use of enum/match to implement tagged-unions. (of course this has supposed=
ly been around in functional languages for a lot longer)<div><br></div><div=
>Are there any proposals to add features that would streamline the use of t=
agged-unions in C++? .. perhaps some sort of 'enum union' declaration, with=
a corresponding equivalent to rusts' match to quickly access variants</div=
><div><br></div><div><div>Of course C and C++ have always been able to repr=
esent this sort of thing, just in a more manual way (more fine grain contro=
l, but more verbose and error-prone too)</div></div><div><br></div><div>may=
be there are better ways in which the vtable information could be leveraged=
to do a similar job, if there's concern that its just too much complexity =
alongside everything C++ already does.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_98_32578817.1402565013879--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 12 Jun 2014 03:52:57 -0700 (PDT)
Raw View
------=_Part_102_29995832.1402570377380
Content-Type: text/plain; charset=UTF-8
On Thursday, 12 June 2014 10:23:34 UTC+1, walter1234 wrote:
>
> Having been looking into Rust, one of the best bits is its use of
> enum/match to implement tagged-unions. (of course this has supposedly been
> around in functional languages for a lot longer)
>
> Are there any proposals to add features that would streamline the use of
> tagged-unions in C++? .. perhaps some sort of 'enum union' declaration,
> with a corresponding equivalent to rusts' match to quickly access variants
>
> Of course C and C++ have always been able to represent this sort of
> thing, just in a more manual way (more fine grain control, but more verbose
> and error-prone too)
>
> maybe there are better ways in which the vtable information could be
> leveraged to do a similar job, if there's concern that its just too much
> complexity alongside everything C++ already does.
>
Best adding a class to the library, something along the lines of
std::optional. I also miss some sort of tagged unions from when I used to
program in Pascal.
--
---
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_102_29995832.1402570377380
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><BR>On Thursday, 12 June 2014 10:23:34 UTC+1, walter1234 wrote:
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV dir=ltr>Having been looking into Rust, one of the best bits is its use of enum/match to implement tagged-unions. (of course this has supposedly been around in functional languages for a lot longer)
<DIV><BR></DIV>
<DIV>Are there any proposals to add features that would streamline the use of tagged-unions in C++? .. perhaps some sort of 'enum union' declaration, with a corresponding equivalent to rusts' match to quickly access variants</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>Of course C and C++ have always been able to represent this sort of thing, just in a more manual way (more fine grain control, but more verbose and error-prone too)</DIV></DIV>
<DIV><BR></DIV>
<DIV>maybe there are better ways in which the vtable information could be leveraged to do a similar job, if there's concern that its just too much complexity alongside everything C++ already does.</DIV></DIV></BLOCKQUOTE>
<DIV> </DIV>
<DIV>Best adding a class to the library, something along the lines of std::optional. I also miss some sort of tagged unions from when I used to program in Pascal.</DIV></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_102_29995832.1402570377380--
.
Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Thu, 12 Jun 2014 14:44:28 +0200
Raw View
On Thu, Jun 12, 2014 at 11:23 AM, walter1234 wrote:
> Having been looking into Rust, one of the best bits is its use of enum/match
> to implement tagged-unions. (of course this has supposedly been around in
> functional languages for a lot longer)
>
> Are there any proposals to add features that would streamline the use of
> tagged-unions in C++? .. perhaps some sort of 'enum union' declaration, with
> a corresponding equivalent to rusts' match to quickly access variants
>
> Of course C and C++ have always been able to represent this sort of thing,
> just in a more manual way (more fine grain control, but more verbose and
> error-prone too)
>
> maybe there are better ways in which the vtable information could be
> leveraged to do a similar job, if there's concern that its just too much
> complexity alongside everything C++ already does.
You get tagged unions with boost::variant<>. But pattern-matching
those is a different story. I don't see how one could add
"destructuring binds" like it's possible in Rust to C++ "in a good
way".
If you only want to match the different variants (ignoring ther inner
details), then maybe there is a way to add sugar to C++ to simplify
the static visitor pattern in a more "lambda-style" way. For example:
variant<string,int> myvariant = ...;
match (myvariant) { // <-- no fall-through switch
case(string const& s): {...} // <-- no break required
case(int i): {...}
}
could be de-sugared into
variant<string,int> myvariant = ...;
{
struct unspeakable_unique_name {
void* stackframe; // like a lambda with capture [&]
void operator()(string const& s) const {...}
void operator()(int i) const {...}
} visitor = some_magical_initialization;
visit(myvariant,visitor); // ADL where ::std is considered associated
}
How about that?
Is it really worth adding this desugaring to the core-language?
I don't know...
Cheers!
sg
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 12 Jun 2014 15:51:09 +0300
Raw View
------ZRAS3Y7OOHV72OF5WRVNI6XCK5XENN
Content-Type: text/plain; charset=UTF-8
This thread should just discuss the following paper it seems, for what concerns lots of the answers it seeks, as well as the proper questions.
www.stroustrup.com/OpenPatternMatching.pdf
George
On June 12, 2014 3:44:28 PM EEST, Sebastian Gesemann <s.gesemann@gmail.com> wrote:
>On Thu, Jun 12, 2014 at 11:23 AM, walter1234 wrote:
>> Having been looking into Rust, one of the best bits is its use of
>enum/match
>> to implement tagged-unions. (of course this has supposedly been
>around in
>> functional languages for a lot longer)
>>
>> Are there any proposals to add features that would streamline the use
>of
>> tagged-unions in C++? .. perhaps some sort of 'enum union'
>declaration, with
>> a corresponding equivalent to rusts' match to quickly access variants
>>
>> Of course C and C++ have always been able to represent this sort of
>thing,
>> just in a more manual way (more fine grain control, but more verbose
>and
>> error-prone too)
>>
>> maybe there are better ways in which the vtable information could be
>> leveraged to do a similar job, if there's concern that its just too
>much
>> complexity alongside everything C++ already does.
>
>You get tagged unions with boost::variant<>. But pattern-matching
>those is a different story. I don't see how one could add
>"destructuring binds" like it's possible in Rust to C++ "in a good
>way".
>
>If you only want to match the different variants (ignoring ther inner
>details), then maybe there is a way to add sugar to C++ to simplify
>the static visitor pattern in a more "lambda-style" way. For example:
>
> variant<string,int> myvariant = ...;
> match (myvariant) { // <-- no fall-through switch
> case(string const& s): {...} // <-- no break required
> case(int i): {...}
> }
>
>could be de-sugared into
>
> variant<string,int> myvariant = ...;
> {
> struct unspeakable_unique_name {
> void* stackframe; // like a lambda with capture [&]
> void operator()(string const& s) const {...}
> void operator()(int i) const {...}
> } visitor = some_magical_initialization;
> visit(myvariant,visitor); // ADL where ::std is considered associated
> }
>
>How about that?
>Is it really worth adding this desugaring to the core-language?
>I don't know...
>
>Cheers!
>sg
>
>--
>
>---
>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/.
--
---
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/.
------ZRAS3Y7OOHV72OF5WRVNI6XCK5XENN
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">This thread should just discuss the=
following paper it seems, for what concerns lots of the answers it seeks, =
as well as the proper questions.</p>
<p dir=3D"ltr">www.stroustrup.com/OpenPatternMatching.pdf</p>
<p dir=3D"ltr">George</p>
<br><br><div class=3D"gmail_quote">On June 12, 2014 3:44:28 PM EEST, Sebast=
ian Gesemann <s.gesemann@gmail.com> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, =
204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Thu, Jun 12, 2014 at 11:23 AM, walter1234 wrote:<b=
r /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; b=
order-left: 1px solid #729fcf; padding-left: 1ex;"> Having been looking int=
o Rust, one of the best bits is its use of enum/match<br /> to implement ta=
gged-unions. (of course this has supposedly been around in<br /> functional=
languages for a lot longer)<br /><br /> Are there any proposals to add fea=
tures that would streamline the use of<br /> tagged-unions in C++? .. perha=
ps some sort of 'enum union' declaration, with<br /> a corresponding equiva=
lent to rusts' match to quickly access variants<br /><br /> Of course C and=
C++ have always been able to represent this sort of thing,<br /> just in a=
more manual way (more fine grain control, but more verbose and<br /> error=
-prone too)<br /><br /> maybe there are better ways in which the vtable inf=
ormation could be<br /> leveraged to do a similar job, if there's concern t=
hat its just too much<br />
complexity alongside everything C++ already does.<br /></blockquote><br />Y=
ou get tagged unions with boost::variant<>. But pattern-matching<br /=
>those is a different story. I don't see how one could add<br />"destructur=
ing binds" like it's possible in Rust to C++ "in a good<br />way".<br /><br=
/>If you only want to match the different variants (ignoring ther inner<br=
/>details), then maybe there is a way to add sugar to C++ to simplify<br /=
>the static visitor pattern in a more "lambda-style" way. For example:<br /=
><br /> variant<string,int> myvariant =3D ...;<br /> match (myvaria=
nt) { // <-- no fall-through switch<br /> case(string const& s): =
{...} // <-- no break required<br /> case(int i): {...}<br /> }<br /=
><br />could be de-sugared into<br /><br /> variant<string,int> myva=
riant =3D ...;<br /> {<br /> struct unspeakable_unique_name {<br /> =
void* stackframe; // like a lambda with capture [&]<br /> void o=
perator()(string
const& s) const {...}<br /> void operator()(int i) const {...}<br =
/> } visitor =3D some_magical_initialization;<br /> visit(myvariant,v=
isitor); // ADL where ::std is considered associated<br /> }<br /><br />Ho=
w about that?<br />Is it really worth adding this desugaring to the core-la=
nguage?<br />I don't know...<br /><br />Cheers!<br />sg<br /></pre></blockq=
uote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------ZRAS3Y7OOHV72OF5WRVNI6XCK5XENN--
.
Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Thu, 12 Jun 2014 14:52:01 +0200
Raw View
On Thu, Jun 12, 2014 at 2:44 PM, Sebastian Gesemann
<s.gesemann@gmail.com> wrote:
> On Thu, Jun 12, 2014 at 11:23 AM, walter1234 wrote:
>> Having been looking into Rust, one of the best bits is its use of enum/match
>> to implement tagged-unions. (of course this has supposedly been around in
>> functional languages for a lot longer)
>>
>> Are there any proposals to add features that would streamline the use of
>> tagged-unions in C++? .. perhaps some sort of 'enum union' declaration, with
>> a corresponding equivalent to rusts' match to quickly access variants
>>
>> Of course C and C++ have always been able to represent this sort of thing,
>> just in a more manual way (more fine grain control, but more verbose and
>> error-prone too)
>>
>> maybe there are better ways in which the vtable information could be
>> leveraged to do a similar job, if there's concern that its just too much
>> complexity alongside everything C++ already does.
>
> You get tagged unions with boost::variant<>. But pattern-matching
> those is a different story. I don't see how one could add
> "destructuring binds" like it's possible in Rust to C++ "in a good
> way".
>
> If you only want to match the different variants (ignoring ther inner
> details), then maybe there is a way to add sugar to C++ to simplify
> the static visitor pattern in a more "lambda-style" way. For example:
>
> variant<string,int> myvariant = ...;
> match (myvariant) { // <-- no fall-through switch
> case(string const& s): {...} // <-- no break required
> case(int i): {...}
> }
>
> could be de-sugared into
>
> variant<string,int> myvariant = ...;
> {
> struct unspeakable_unique_name {
> void* stackframe; // like a lambda with capture [&]
> void operator()(string const& s) const {...}
> void operator()(int i) const {...}
> } visitor = some_magical_initialization;
> visit(myvariant,visitor); // ADL where ::std is considered associated
> }
>
> How about that?
> Is it really worth adding this desugaring to the core-language?
> I don't know...
This "match" really is sort of a "type switch". And having this term
in mind I remembered this:
https://isocpp.org/blog/2013/02/open-and-efficient-type-switch-for-c-solodkyy-dos-reis-and-stroustrup
But their works seems restricted to class hierarchies.
--
---
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/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Thu, 12 Jun 2014 10:36:29 -0400
Raw View
On Thu, Jun 12, 2014 at 8:44 AM, Sebastian Gesemann
<s.gesemann@gmail.com> wrote:
>
> variant<string,int> myvariant = ...;
> {
> struct unspeakable_unique_name {
> void* stackframe; // like a lambda with capture [&]
> void operator()(string const& s) const {...}
> void operator()(int i) const {...}
> } visitor = some_magical_initialization;
> visit(myvariant,visitor); // ADL where ::std is considered associated
> }
You don't even need a named type, neither the operators.
Try https://gist.github.com/gintenlabo/6363346 (originated from Dave
Abrahams)
visit(myvariant, make_overloaded(
[&](string const& s) { ... },
[&](int i) { ... }));
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: Sebastian Gesemann <s.gesemann@gmail.com>
Date: Thu, 12 Jun 2014 18:09:08 +0200
Raw View
On Thu, Jun 12, 2014 at 4:36 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Thu, Jun 12, 2014 at 8:44 AM, Sebastian Gesemann
> <s.gesemann@gmail.com> wrote:
>>
>> variant<string,int> myvariant = ...;
>> {
>> struct unspeakable_unique_name {
>> void* stackframe; // like a lambda with capture [&]
>> void operator()(string const& s) const {...}
>> void operator()(int i) const {...}
>> } visitor = some_magical_initialization;
>> visit(myvariant,visitor); // ADL where ::std is considered associated
>> }
>
> You don't even need a named type, neither the operators.
>
> Try https://gist.github.com/gintenlabo/6363346 (originated from Dave
> Abrahams)
>
> visit(myvariant, make_overloaded(
> [&](string const& s) { ... },
> [&](int i) { ... }));
Thanks for pointing this out. It's certainly an interesting
library-only approach. The only thing that would bug me a little is
that it could make the resultung functor unnecessarily large due to
possibly redundant lambda captures. Other than that, it looks fine and
actually usable. :-)
--
---
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/.
.
Author: walter1234 <walter2bz@gmail.com>
Date: Thu, 12 Jun 2014 10:45:40 -0700 (PDT)
Raw View
------=_Part_370_203011.1402595140733
Content-Type: text/plain; charset=UTF-8
ok I've seen these sort of 'workarounds' , you'd hope the whole thing would
inline so it would be directly comparable to a match expression.
you still have some more hoops to jump through: when you create a variant,
you supply types for the variants, so you need to create types for each,
whereas in rust you just write enum { ... variants.. } and it handles all
the boilerplate for setting it up
Point taken that some of the uses of enum/match in rust can be handled with
special case classes (like optional, and in rust they also provide special
methods to avoid using match).
So these workarounds exist, but they still don't seem as elegant as what
can be done in rust.
This leaves me wondering, just like polymorphic lambdas are simply sugar
over rolling a functor class, whether an addition to the language could
streamline it, and make it more elegant, and reduce the gap between c++ and
rust on this specific front.
Also consider compile times: if you were to make extensive use of this and
it was a template, you're relying on the compiler to do a lot more work,
compared to if it was a built in language feature.
On Thursday, 12 June 2014 17:09:10 UTC+1, Sebastian Gesemann wrote:
>
> On Thu, Jun 12, 2014 at 4:36 PM, Zhihao Yuan <z...@miator.net
> <javascript:>> wrote:
> > On Thu, Jun 12, 2014 at 8:44 AM, Sebastian Gesemann
> > <s.ges...@gmail.com <javascript:>> wrote:
> >>
> >> variant<string,int> myvariant = ...;
> >> {
> >> struct unspeakable_unique_name {
> >> void* stackframe; // like a lambda with capture [&]
> >> void operator()(string const& s) const {...}
> >> void operator()(int i) const {...}
> >> } visitor = some_magical_initialization;
> >> visit(myvariant,visitor); // ADL where ::std is considered
> associated
> >> }
> >
> > You don't even need a named type, neither the operators.
> >
> > Try https://gist.github.com/gintenlabo/6363346 (originated from Dave
> > Abrahams)
> >
> > visit(myvariant, make_overloaded(
> > [&](string const& s) { ... },
> > [&](int i) { ... }));
>
> Thanks for pointing this out. It's certainly an interesting
> library-only approach. The only thing that would bug me a little is
> that it could make the resultung functor unnecessarily large due to
> possibly redundant lambda captures. Other than that, it looks fine and
> actually usable. :-)
>
--
---
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_370_203011.1402595140733
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">ok I've seen these sort of 'workarounds' , you'd hope the =
whole thing would inline so it would be directly comparable to a match expr=
ession.<div><br><div>you still have some more hoops to jump through: when y=
ou create a variant, you supply types for the variants, so you need to crea=
te types for each, whereas in rust you just write enum { ... variants.. } a=
nd it handles all the boilerplate for setting it up</div><div><br></div><di=
v>Point taken that some of the uses of enum/match in rust can be handled wi=
th special case classes (like optional, and in rust they also provide speci=
al methods to avoid using match).</div><div><br></div><div>So these workaro=
unds exist, but they still don't seem as elegant as what can be done in rus=
t.</div><div><br></div><div>This leaves me wondering, just like polymorphic=
lambdas are simply sugar over rolling a functor class, whether an addition=
to the language could streamline it, and make it more elegant, and reduce =
the gap between c++ and rust on this specific front.<br><br>Also consider c=
ompile times: if you were to make extensive use of this and it was a templa=
te, you're relying on the compiler to do a lot more work, compared to if it=
was a built in language feature.<br><br>On Thursday, 12 June 2014 17:09:10=
UTC+1, Sebastian Gesemann wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Thu, Jun 12, 2014 at 4:36 PM, Zhihao Yuan <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"ydJQmp9BoWYJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">z...@miator.net</a>> wrote:
<br>> On Thu, Jun 12, 2014 at 8:44 AM, Sebastian Gesemann
<br>> <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ydJQmp9BoWYJ" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">s.ges...@gmail.com</a>>=
; wrote:
<br>>>
<br>>> variant<string,int> myvariant =3D ...;
<br>>> {
<br>>> struct unspeakable_unique_name {
<br>>> void* stackframe; // like a lambda with c=
apture [&]
<br>>> void operator()(string const& s) cons=
t {...}
<br>>> void operator()(int i) const {...}
<br>>> } visitor =3D some_magical_initialization;
<br>>> visit(myvariant,visitor); // ADL where ::std is =
considered associated
<br>>> }
<br>>
<br>> You don't even need a named type, neither the operators.
<br>>
<br>> Try <a href=3D"https://gist.github.com/gintenlabo/6363346" target=
=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fgist.github.com%2Fgintenlabo%2F6363346\46sa\75D\46sntz\0751\46usg=
\75AFQjCNF9ldnxN24wDCehP-90Z-XScOFdrw';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fgintenla=
bo%2F6363346\46sa\75D\46sntz\0751\46usg\75AFQjCNF9ldnxN24wDCehP-90Z-XScOFdr=
w';return true;">https://gist.github.com/<wbr>gintenlabo/6363346</a> (origi=
nated from Dave
<br>> Abrahams)
<br>>
<br>> visit(myvariant, make_overloaded(
<br>> [&](string const& s) { ... },
<br>> [&](int i) { ... }));
<br>
<br>Thanks for pointing this out. It's certainly an interesting
<br>library-only approach. The only thing that would bug me a little is
<br>that it could make the resultung functor unnecessarily large due to
<br>possibly redundant lambda captures. Other than that, it looks fine and
<br>actually usable. :-)
<br></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_370_203011.1402595140733--
.