--f46d04447e61a947f304cf7b26ae
Content-Type: text/plain; charset=ISO-8859-1

I've been thinking about how pattern-matching of types could
be done in expressions, as opposed to only in template
specialisation definitions.  These are more assorted ideas
than a well-formed proposal; I do not possess the
understanding to determine whether this is implementable or
not.

The most basic form is

    X[PARAMS][PATTERN]

which, in a boolean context, expands to match<X>::value
where

    template<typename>
    struct match : std::false_type {};

    template<PARAMS>
    struct match<PATTERN> : std::true_type {};

Example usages:

A replacement for std::is_const:

    X[typename T][T const]

Matching an array of any size, of a given type:

    X[size_t N][array<int, N>]

A replacement for std::is_same:

    X[][Y]


In a context where a type is expected, the aforementioned
syntax is an error when the match fails (substitution
failure when appropriate?).  When it succeeds, the result
evaluates to a struct where every template parameter is
typedeffed to its name, and every non-typename parameter is
defined as a static constexpr value of that type.

Once again, examples:

Remove (non-const, lvalue) reference:

    X[typename T][T&]::T

Get size of array type:

    X[typename T, size_t N][array<T, N>]::N

Get return value of nullary function:

    X[typename T][T()]::T

Get types of the first two parameters of a function:

    using R = X[typename T1, typename T2][void (T1, T2)];

I'm not sure how to handle template template parameters
here.  I suspect creating a template typedef could be done.
This would allow extraction like this:

    X[template<typename> class C, typename T][C<T>]::C

If a parameter is listed but not used, it should probably
evaluate to void; this is convenient for the choice idea
below.  However, for single patterns it may make more sense
to make it a compile error.

In order to save people the trouble of extra typing, any
typename that should not be captured can be replaced with
"auto".  Every instance of auto creates an implicit extra
template parameter for match, which does not get typedeffed
as described above.  A non-typename parameter may be aliased
with auto by using "auto T", where T is the type the
parameter should be.

More examples:

Any array:

    X[][array<auto, auto size_t>]

Desugars into:

    template<typename>
    struct match : std::false_type {};

    template<typename _UnnamedT1, size_t _UnnamedT2>
    struct match<array<_UnnamedT1, _UnnamedT2>> : std::true_type {};


Return type of any binary function:

    X[typename T][T(auto, auto)]::T

Desugars into (the currently impossible):

    template<typename>
    struct match {};

    template<typename T, typename _UnnamedT1, typename _UnnamedT2>
    struct match<T(_UnnamedT1, _UnnamedT2)> {
        using T = T;
    };


Another desired property is variadic argument support.  The
following demonstrates the intent:

    using V = X[typename T, typename... Args][T(Args...)];

should match all functions.  This is currently impossible as
the parameter pack must be expanded; I honestly have no clue
what to do about this.  The same can be done with auto if
desired:

    X[typename T][T(auto...)]::T

should get the return value of any function.


Choice would be nice, and the | operator would make sense
for it. For instance, remove_reference could be done with:

    X[typename T][T& | T&&]::T


A choice of part of an expression should expand to a choice
over the whole expression:

    X[typename T][vector<(T | pair<T, T>)>]

is

    X[typename T][vector<T> | vector<pair<T, T>>]


This raises a lot of questions, for which I don't have
answers.  I'm not sure how useful allowing subexpression
choice is.  I'm not sure how 5|3 should be interpreted.
(The : operator could be used to avoid this ambiguity.)


And, as a final feature: if we're only interested in
extracting one type or value, using "return" in the same way
we had chosen to use "auto" above should make the match
evaluate to that type.  That is:

    X[][vector<auto, return>]

should expand to match<X>::type where

    template<typename>
    struct match {};

    template<typename _UnnamedT1, typename _Result>
    struct match<vector<_UnnamedT1, _Result>> {
        using type = _Result;
    };

I'm not yet sure how return would interact with template
template parameters and such.

I suspect these features to be most useful in combination
with static if.  I felt this may be useful after looking at
whether constexpr functions taking and returning typenames
would make sense, and noticing that a lot would still have
to be done with templates due to pattern-matching being
limited to those.

Would this be worth adding?  Am I overlooking anything?

Best regards,
Anton Golov

--




--f46d04447e61a947f304cf7b26ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I&#39;ve been thinking about how pattern-matching of types could</div>=
<div>be done in expressions, as opposed to only in template</div><div>speci=
alisation definitions. =A0These are more assorted ideas</div><div>than a we=
ll-formed proposal; I do not possess the</div>
<div>understanding to determine whether this is implementable or</div><div>=
not.</div><div><br></div><div>The most basic form is</div><div><br></div><d=
iv>=A0 =A0 X[PARAMS][PATTERN]</div><div><br></div><div>which, in a boolean =
context, expands to match&lt;X&gt;::value</div>
<div>where</div><div><br></div><div>=A0 =A0 template&lt;typename&gt;</div><=
div>=A0 =A0 struct match : std::false_type {};</div><div><br></div><div>=A0=
 =A0 template&lt;PARAMS&gt;</div><div>=A0 =A0 struct match&lt;PATTERN&gt; :=
 std::true_type {};</div>
<div><br></div><div>Example usages:</div><div><br></div><div>A replacement =
for std::is_const:</div><div><br></div><div>=A0 =A0 X[typename T][T const]<=
/div><div><br></div><div>Matching an array of any size, of a given type:</d=
iv>
<div><br></div><div>=A0 =A0 X[size_t N][array&lt;int, N&gt;]</div><div><br>=
</div><div>A replacement for std::is_same:</div><div><br></div><div>=A0 =A0=
 X[][Y]</div><div><br></div><div><br></div><div>In a context where a type i=
s expected, the aforementioned</div>
<div>syntax is an error when the match fails (substitution</div><div>failur=
e when appropriate?). =A0When it succeeds, the result</div><div>evaluates t=
o a struct where every template parameter is</div><div>typedeffed to its na=
me, and every non-typename parameter is</div>
<div>defined as a static constexpr value of that type.</div><div><br></div>=
<div>Once again, examples:</div><div><br></div><div>Remove (non-const, lval=
ue) reference:</div><div><br></div><div>=A0 =A0 X[typename T][T&amp;]::T</d=
iv>
<div><br></div><div>Get size of array type:</div><div><br></div><div>=A0 =
=A0 X[typename T, size_t N][array&lt;T, N&gt;]::N</div><div><br></div><div>=
Get return value of nullary function:</div><div><br></div><div>=A0 =A0 X[ty=
pename T][T()]::T</div>
<div><br></div><div>Get types of the first two parameters of a function:</d=
iv><div><br></div><div>=A0 =A0 using R =3D X[typename T1, typename T2][void=
 (T1, T2)];</div><div><br></div><div>I&#39;m not sure how to handle templat=
e template parameters</div>
<div>here. =A0I suspect creating a template typedef could be done.</div><di=
v>This would allow extraction like this:</div><div><br></div><div>=A0 =A0 X=
[template&lt;typename&gt; class C, typename T][C&lt;T&gt;]::C</div><div><br=
></div>
<div>If a parameter is listed but not used, it should probably</div><div>ev=
aluate to void; this is convenient for the choice idea</div><div>below. =A0=
However, for single patterns it may make more sense</div><div>to make it a =
compile error.</div>
<div><br></div><div>In order to save people the trouble of extra typing, an=
y</div><div>typename that should not be captured can be replaced with</div>=
<div>&quot;auto&quot;. =A0Every instance of auto creates an implicit extra<=
/div>
<div>template parameter for match, which does not get typedeffed</div><div>=
as described above. =A0A non-typename parameter may be aliased</div><div>wi=
th auto by using &quot;auto T&quot;, where T is the type the</div><div>para=
meter should be.</div>
<div><br></div><div>More examples:</div><div><br></div><div>Any array:</div=
><div><br></div><div>=A0 =A0 X[][array&lt;auto, auto size_t&gt;]</div><div>=
<br></div><div>Desugars into:</div><div><br></div><div>=A0 =A0 template&lt;=
typename&gt;</div>
<div>=A0 =A0 struct match : std::false_type {};</div><div><br></div><div>=
=A0 =A0 template&lt;typename _UnnamedT1, size_t _UnnamedT2&gt;</div><div>=
=A0 =A0 struct match&lt;array&lt;_UnnamedT1, _UnnamedT2&gt;&gt; : std::true=
_type {};</div>
<div><br></div><div><br></div><div>Return type of any binary function:</div=
><div><br></div><div>=A0 =A0 X[typename T][T(auto, auto)]::T</div><div><br>=
</div><div>Desugars into (the currently impossible):</div><div><br></div><d=
iv>
=A0 =A0 template&lt;typename&gt;</div><div>=A0 =A0 struct match {};</div><d=
iv><br></div><div>=A0 =A0 template&lt;typename T, typename _UnnamedT1, type=
name _UnnamedT2&gt;</div><div>=A0 =A0 struct match&lt;T(_UnnamedT1, _Unname=
dT2)&gt; {</div>
<div>=A0 =A0 =A0 =A0 using T =3D T;</div><div>=A0 =A0 };</div><div><br></di=
v><div><br></div><div>Another desired property is variadic argument support=
.. =A0The</div><div>following demonstrates the intent:</div><div><br></div><=
div>=A0 =A0 using V =3D X[typename T, typename... Args][T(Args...)];</div>
<div><br></div><div>should match all functions. =A0This is currently imposs=
ible as</div><div>the parameter pack must be expanded; I honestly have no c=
lue</div><div>what to do about this. =A0The same can be done with auto if</=
div>
<div>desired:</div><div><br></div><div>=A0 =A0 X[typename T][T(auto...)]::T=
</div><div><br></div><div>should get the return value of any function.</div=
><div><br></div><div><br></div><div>Choice would be nice, and the | operato=
r would make sense</div>
<div>for it. For instance, remove_reference could be done with:</div><div><=
br></div><div>=A0 =A0 X[typename T][T&amp; | T&amp;&amp;]::T</div><div><br>=
</div><div><br></div><div>A choice of part of an expression should expand t=
o a choice</div>
<div>over the whole expression:</div><div><br></div><div>=A0 =A0 X[typename=
 T][vector&lt;(T | pair&lt;T, T&gt;)&gt;]</div><div><br></div><div>is</div>=
<div><br></div><div>=A0 =A0 X[typename T][vector&lt;T&gt; | vector&lt;pair&=
lt;T, T&gt;&gt;]</div>
<div><br></div><div><br></div><div>This raises a lot of questions, for whic=
h I don&#39;t have</div><div>answers. =A0I&#39;m not sure how useful allowi=
ng subexpression</div><div>choice is. =A0I&#39;m not sure how 5|3 should be=
 interpreted.</div>
<div>(The : operator could be used to avoid this ambiguity.)</div><div><br>=
</div><div><br></div><div>And, as a final feature: if we&#39;re only intere=
sted in</div><div>extracting one type or value, using &quot;return&quot; in=
 the same way</div>
<div>we had chosen to use &quot;auto&quot; above should make the match</div=
><div>evaluate to that type. =A0That is:</div><div><br></div><div>=A0 =A0 X=
[][vector&lt;auto, return&gt;]</div><div><br></div><div>should expand to ma=
tch&lt;X&gt;::type where</div>
<div><br></div><div>=A0 =A0 template&lt;typename&gt;</div><div>=A0 =A0 stru=
ct match {};</div><div><br></div><div>=A0 =A0 template&lt;typename _Unnamed=
T1, typename _Result&gt;</div><div>=A0 =A0 struct match&lt;vector&lt;_Unnam=
edT1, _Result&gt;&gt; {</div>
<div>=A0 =A0 =A0 =A0 using type =3D _Result;</div><div>=A0 =A0 };</div><div=
><br></div><div>I&#39;m not yet sure how return would interact with templat=
e</div><div>template parameters and such.</div><div><br></div><div>I suspec=
t these features to be most useful in combination</div>
<div>with static if. =A0I felt this may be useful after looking at</div><di=
v>whether constexpr functions taking and returning typenames</div><div>woul=
d make sense, and noticing that a lot would still have</div><div>to be done=
 with templates due to pattern-matching being</div>
<div>limited to those.</div><div><br></div><div>Would this be worth adding?=
 =A0Am I overlooking anything?</div><div><br></div><div>Best regards,</div>=
<div>Anton Golov</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d04447e61a947f304cf7b26ae--

.

On 11/27/12, Anton Golov <jesyspa@gmail.com> wrote:
> I've been thinking about how pattern-matching of types could
> be done in expressions, as opposed to only in template
> specialisation definitions.  These are more assorted ideas
> than a well-formed proposal; I do not possess the
> understanding to determine whether this is implementable or
> not.

We need some hand holding here.  Start with the programming problem
you are trying to solve.  Show us code that is either impossible or
clumsy with the existing language.  Then outline your solution, and
show us the code as it would appear with your solution.  Only then
will we be able to give useful feedback on the feature.

>
> The most basic form is
>
>     X[PARAMS][PATTERN]
>
> which, in a boolean context, expands to match<X>::value
> where
>
>     template<typename>
>     struct match : std::false_type {};
>
>     template<PARAMS>
>     struct match<PATTERN> : std::true_type {};
>
> Example usages:
>
> A replacement for std::is_const:
>
>     X[typename T][T const]
>
> Matching an array of any size, of a given type:
>
>     X[size_t N][array<int, N>]
>
> A replacement for std::is_same:
>
>     X[][Y]
>
>
> In a context where a type is expected, the aforementioned
> syntax is an error when the match fails (substitution
> failure when appropriate?).  When it succeeds, the result
> evaluates to a struct where every template parameter is
> typedeffed to its name, and every non-typename parameter is
> defined as a static constexpr value of that type.
>
> Once again, examples:
>
> Remove (non-const, lvalue) reference:
>
>     X[typename T][T&]::T
>
> Get size of array type:
>
>     X[typename T, size_t N][array<T, N>]::N
>
> Get return value of nullary function:
>
>     X[typename T][T()]::T
>
> Get types of the first two parameters of a function:
>
>     using R = X[typename T1, typename T2][void (T1, T2)];
>
> I'm not sure how to handle template template parameters
> here.  I suspect creating a template typedef could be done.
> This would allow extraction like this:
>
>     X[template<typename> class C, typename T][C<T>]::C
>
> If a parameter is listed but not used, it should probably
> evaluate to void; this is convenient for the choice idea
> below.  However, for single patterns it may make more sense
> to make it a compile error.
>
> In order to save people the trouble of extra typing, any
> typename that should not be captured can be replaced with
> "auto".  Every instance of auto creates an implicit extra
> template parameter for match, which does not get typedeffed
> as described above.  A non-typename parameter may be aliased
> with auto by using "auto T", where T is the type the
> parameter should be.
>
> More examples:
>
> Any array:
>
>     X[][array<auto, auto size_t>]
>
> Desugars into:
>
>     template<typename>
>     struct match : std::false_type {};
>
>     template<typename _UnnamedT1, size_t _UnnamedT2>
>     struct match<array<_UnnamedT1, _UnnamedT2>> : std::true_type {};
>
>
> Return type of any binary function:
>
>     X[typename T][T(auto, auto)]::T
>
> Desugars into (the currently impossible):
>
>     template<typename>
>     struct match {};
>
>     template<typename T, typename _UnnamedT1, typename _UnnamedT2>
>     struct match<T(_UnnamedT1, _UnnamedT2)> {
>         using T = T;
>     };
>
>
> Another desired property is variadic argument support.  The
> following demonstrates the intent:
>
>     using V = X[typename T, typename... Args][T(Args...)];
>
> should match all functions.  This is currently impossible as
> the parameter pack must be expanded; I honestly have no clue
> what to do about this.  The same can be done with auto if
> desired:
>
>     X[typename T][T(auto...)]::T
>
> should get the return value of any function.
>
>
> Choice would be nice, and the | operator would make sense
> for it. For instance, remove_reference could be done with:
>
>     X[typename T][T& | T&&]::T
>
>
> A choice of part of an expression should expand to a choice
> over the whole expression:
>
>     X[typename T][vector<(T | pair<T, T>)>]
>
> is
>
>     X[typename T][vector<T> | vector<pair<T, T>>]
>
>
> This raises a lot of questions, for which I don't have
> answers.  I'm not sure how useful allowing subexpression
> choice is.  I'm not sure how 5|3 should be interpreted.
> (The : operator could be used to avoid this ambiguity.)
>
>
> And, as a final feature: if we're only interested in
> extracting one type or value, using "return" in the same way
> we had chosen to use "auto" above should make the match
> evaluate to that type.  That is:
>
>     X[][vector<auto, return>]
>
> should expand to match<X>::type where
>
>     template<typename>
>     struct match {};
>
>     template<typename _UnnamedT1, typename _Result>
>     struct match<vector<_UnnamedT1, _Result>> {
>         using type = _Result;
>     };
>
> I'm not yet sure how return would interact with template
> template parameters and such.
>
> I suspect these features to be most useful in combination
> with static if.  I felt this may be useful after looking at
> whether constexpr functions taking and returning typenames
> would make sense, and noticing that a lot would still have
> to be done with templates due to pattern-matching being
> limited to those.
>
> Would this be worth adding?  Am I overlooking anything?
>
> Best regards,
> Anton Golov
>
> --
>
>
>
>


--
Lawrence Crowl

--




.

Le 27/11/12 15:49, Anton Golov a =E9crit :
> I've been thinking about how pattern-matching of types could
> be done in expressions, as opposed to only in template
> specialisation definitions.  These are more assorted ideas
> than a well-formed proposal; I do not possess the
> understanding to determine whether this is implementable or
> not.
>
> The most basic form is
>
>     X[PARAMS][PATTERN]
>
> which, in a boolean context, expands to match<X>::value
> where
>
>     template<typename>
>     struct match : std::false_type {};
>
>     template<PARAMS>
>     struct match<PATTERN> : std::true_type {};
>
> Example usages:
>
> A replacement for std::is_const:
>
>     X[typename T][T const]
>
> Matching an array of any size, of a given type:
>
>     X[size_t N][array<int, N>]
>
> A replacement for std::is_same:
>
>     X[][Y]
>
>
>
Hi,

We could use the current syntax. With C++ we could define a template=20
match that could allow you to check

A replacement for std::is_const:

   match<_T const, X>

where _T is a pattern variable

Matching an array of any size, of a given type:

   match<_array_<int, _N>, X>

where _array_ is and artificial template accepting pattern variables,=20
even those representing non-type parameters

A replacement for std::is_same:

   match<Y, X>

A extract meta-function could be defined in the same way and allows to

The main problem is that defining this template is cumbersome. Of course=20
the compiler could use other techniques to check if there is a match and=20
get rid of the _array_ trick.

extract<_T &, _T, X>

instead of

remove_reference<X>

The question is which is the added value. Will the end-user understand=20
better pattern matching than specific meta-functions?
Which meta-programming style will result with this addition and how=20
could it be better.

  Why not define specific templates to that match the specific pattern

template <typename ARRAY>
struct do_something;

template <typename T, size_t N>
struct do_something<array<T,N>> {...};

do_something<X>

-- Vicente

P.S. If there is an interest, I could share privately the ideas on how=20
the match and extract templates could be implemented as a library on=20
C++11 (not checked with a compiler yet). Note that the design doesn't=20
scales well and needs a lot of specificities from each specific class=20
template.

--=20




.

------=_Part_47_13714374.1354855986608
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

@viboes: This is interesting at least from a user point of view. May it=20
will be good to work on a library and post it here. If you need any help=20
let me know. Is it something like Metaparse proposed for boost?

On Thursday, November 29, 2012 4:47:20 AM UTC+5:30, viboes wrote:
>
> Le 27/11/12 15:49, Anton Golov a =EF=BF=BDcrit :=20
> > I've been thinking about how pattern-matching of types could=20
> > be done in expressions, as opposed to only in template=20
> > specialisation definitions.  These are more assorted ideas=20
> > than a well-formed proposal; I do not possess the=20
> > understanding to determine whether this is implementable or=20
> > not.=20
> >=20
> > The most basic form is=20
> >=20
> >     X[PARAMS][PATTERN]=20
> >=20
> > which, in a boolean context, expands to match<X>::value=20
> > where=20
> >=20
> >     template<typename>=20
> >     struct match : std::false_type {};=20
> >=20
> >     template<PARAMS>=20
> >     struct match<PATTERN> : std::true_type {};=20
> >=20
> > Example usages:=20
> >=20
> > A replacement for std::is_const:=20
> >=20
> >     X[typename T][T const]=20
> >=20
> > Matching an array of any size, of a given type:=20
> >=20
> >     X[size_t N][array<int, N>]=20
> >=20
> > A replacement for std::is_same:=20
> >=20
> >     X[][Y]=20
> >=20
> >=20
> >=20
> Hi,=20
>
> We could use the current syntax. With C++ we could define a template=20
> match that could allow you to check=20
>
> A replacement for std::is_const:=20
>
>    match<_T const, X>=20
>
> where _T is a pattern variable=20
>
> Matching an array of any size, of a given type:=20
>
>    match<_array_<int, _N>, X>=20
>
> where _array_ is and artificial template accepting pattern variables,=20
> even those representing non-type parameters=20
>
> A replacement for std::is_same:=20
>
>    match<Y, X>=20
>
> A extract meta-function could be defined in the same way and allows to=20
>
> The main problem is that defining this template is cumbersome. Of course=
=20
> the compiler could use other techniques to check if there is a match and=
=20
> get rid of the _array_ trick.=20
>
> extract<_T &, _T, X>=20
>
> instead of=20
>
> remove_reference<X>=20
>
> The question is which is the added value. Will the end-user understand=20
> better pattern matching than specific meta-functions?=20
> Which meta-programming style will result with this addition and how=20
> could it be better.=20
>
>   Why not define specific templates to that match the specific pattern=20
>
> template <typename ARRAY>=20
> struct do_something;=20
>
> template <typename T, size_t N>=20
> struct do_something<array<T,N>> {...};=20
>
> do_something<X>=20
>
> -- Vicente=20
>
> P.S. If there is an interest, I could share privately the ideas on how=20
> the match and extract templates could be implemented as a library on=20
> C++11 (not checked with a compiler yet). Note that the design doesn't=20
> scales well and needs a lot of specificities from each specific class=20
> template.=20
>
>

--=20




------=_Part_47_13714374.1354855986608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

@viboes: This is interesting at least from a user point of view. May it wil=
l be=20
good to work on a library and post it here. If you need any help let me=20
know. Is it something like Metaparse proposed for boost?<br><br>On Thursday=
, November 29, 2012 4:47:20 AM UTC+5:30, viboes wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">Le 27/11/12 15:49, Anton Golov a =EF=BF=BDcrit :
<br>&gt; I've been thinking about how pattern-matching of types could
<br>&gt; be done in expressions, as opposed to only in template
<br>&gt; specialisation definitions. &nbsp;These are more assorted ideas
<br>&gt; than a well-formed proposal; I do not possess the
<br>&gt; understanding to determine whether this is implementable or
<br>&gt; not.
<br>&gt;
<br>&gt; The most basic form is
<br>&gt;
<br>&gt; &nbsp; &nbsp; X[PARAMS][PATTERN]
<br>&gt;
<br>&gt; which, in a boolean context, expands to match&lt;X&gt;::value
<br>&gt; where
<br>&gt;
<br>&gt; &nbsp; &nbsp; template&lt;typename&gt;
<br>&gt; &nbsp; &nbsp; struct match : std::false_type {};
<br>&gt;
<br>&gt; &nbsp; &nbsp; template&lt;PARAMS&gt;
<br>&gt; &nbsp; &nbsp; struct match&lt;PATTERN&gt; : std::true_type {};
<br>&gt;
<br>&gt; Example usages:
<br>&gt;
<br>&gt; A replacement for std::is_const:
<br>&gt;
<br>&gt; &nbsp; &nbsp; X[typename T][T const]
<br>&gt;
<br>&gt; Matching an array of any size, of a given type:
<br>&gt;
<br>&gt; &nbsp; &nbsp; X[size_t N][array&lt;int, N&gt;]
<br>&gt;
<br>&gt; A replacement for std::is_same:
<br>&gt;
<br>&gt; &nbsp; &nbsp; X[][Y]
<br>&gt;
<br>&gt;
<br>&gt;
<br>Hi,
<br>
<br>We could use the current syntax. With C++ we could define a template=20
<br>match that could allow you to check
<br>
<br>A replacement for std::is_const:
<br>
<br>&nbsp; &nbsp;match&lt;_T const, X&gt;
<br>
<br>where _T is a pattern variable
<br>
<br>Matching an array of any size, of a given type:
<br>
<br>&nbsp; &nbsp;match&lt;_array_&lt;int, _N&gt;, X&gt;
<br>
<br>where _array_ is and artificial template accepting pattern variables,=
=20
<br>even those representing non-type parameters
<br>
<br>A replacement for std::is_same:
<br>
<br>&nbsp; &nbsp;match&lt;Y, X&gt;
<br>
<br>A extract meta-function could be defined in the same way and allows to
<br>
<br>The main problem is that defining this template is cumbersome. Of cours=
e=20
<br>the compiler could use other techniques to check if there is a match an=
d=20
<br>get rid of the _array_ trick.
<br>
<br>extract&lt;_T &amp;, _T, X&gt;
<br>
<br>instead of
<br>
<br>remove_reference&lt;X&gt;
<br>
<br>The question is which is the added value. Will the end-user understand=
=20
<br>better pattern matching than specific meta-functions?
<br>Which meta-programming style will result with this addition and how=20
<br>could it be better.
<br>
<br>&nbsp; Why not define specific templates to that match the specific pat=
tern
<br>
<br>template &lt;typename ARRAY&gt;
<br>struct do_something;
<br>
<br>template &lt;typename T, size_t N&gt;
<br>struct do_something&lt;array&lt;T,N&gt;&gt; {...};
<br>
<br>do_something&lt;X&gt;
<br>
<br>-- Vicente
<br>
<br>P.S. If there is an interest, I could share privately the ideas on how=
=20
<br>the match and extract templates could be implemented as a library on=20
<br>C++11 (not checked with a compiler yet). Note that the design doesn't=
=20
<br>scales well and needs a lot of specificities from each specific class=
=20
<br>template.
<br>
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_47_13714374.1354855986608--

.

--0016e6de044514510304d03f0f96
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Lawrence, I don't have good answers to these questions, so I've been
working on that.  I think I'll wait until static_if becomes available; it's
hard to come up with use-cases without it.

Vincente, I wouldn't mind changing the syntax; I'm not sure having
something that looks like a template argument but completely isn't would be
a good idea, though.

At least parts of this could be done as a library if it was possible to
define templates in lambdas, thinking about how I could hack my way around
that.


On 7 December 2012 05:53, Shakti Misra <shakti.misra.works@gmail.com> wrote=
:

> @viboes: This is interesting at least from a user point of view. May it
> will be good to work on a library and post it here. If you need any help
> let me know. Is it something like Metaparse proposed for boost?
>
> On Thursday, November 29, 2012 4:47:20 AM UTC+5:30, viboes wrote:
>>
>> Le 27/11/12 15:49, Anton Golov a =EF=BF=BDcrit :
>> > I've been thinking about how pattern-matching of types could
>> > be done in expressions, as opposed to only in template
>> > specialisation definitions.  These are more assorted ideas
>> > than a well-formed proposal; I do not possess the
>> > understanding to determine whether this is implementable or
>> > not.
>> >
>> > The most basic form is
>> >
>> >     X[PARAMS][PATTERN]
>> >
>> > which, in a boolean context, expands to match<X>::value
>> > where
>> >
>> >     template<typename>
>> >     struct match : std::false_type {};
>> >
>> >     template<PARAMS>
>> >     struct match<PATTERN> : std::true_type {};
>> >
>> > Example usages:
>> >
>> > A replacement for std::is_const:
>> >
>> >     X[typename T][T const]
>> >
>> > Matching an array of any size, of a given type:
>> >
>> >     X[size_t N][array<int, N>]
>> >
>> > A replacement for std::is_same:
>> >
>> >     X[][Y]
>> >
>> >
>> >
>> Hi,
>>
>> We could use the current syntax. With C++ we could define a template
>> match that could allow you to check
>>
>> A replacement for std::is_const:
>>
>>    match<_T const, X>
>>
>> where _T is a pattern variable
>>
>> Matching an array of any size, of a given type:
>>
>>    match<_array_<int, _N>, X>
>>
>> where _array_ is and artificial template accepting pattern variables,
>> even those representing non-type parameters
>>
>> A replacement for std::is_same:
>>
>>    match<Y, X>
>>
>> A extract meta-function could be defined in the same way and allows to
>>
>> The main problem is that defining this template is cumbersome. Of course
>> the compiler could use other techniques to check if there is a match and
>> get rid of the _array_ trick.
>>
>> extract<_T &, _T, X>
>>
>> instead of
>>
>> remove_reference<X>
>>
>> The question is which is the added value. Will the end-user understand
>> better pattern matching than specific meta-functions?
>> Which meta-programming style will result with this addition and how
>> could it be better.
>>
>>   Why not define specific templates to that match the specific pattern
>>
>> template <typename ARRAY>
>> struct do_something;
>>
>> template <typename T, size_t N>
>> struct do_something<array<T,N>> {...};
>>
>> do_something<X>
>>
>> -- Vicente
>>
>> P.S. If there is an interest, I could share privately the ideas on how
>> the match and extract templates could be implemented as a library on
>> C++11 (not checked with a compiler yet). Note that the design doesn't
>> scales well and needs a lot of specificities from each specific class
>> template.
>>
>>  --
>
>
>
>

--=20




--0016e6de044514510304d03f0f96
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Lawrence, I don&#39;t have good answers to these questions, so I&#39;ve bee=
n working on that. =A0I think I&#39;ll wait until static_if becomes availab=
le; it&#39;s hard to come up with use-cases without it.<div><br></div><div>
Vincente, I wouldn&#39;t mind changing the syntax; I&#39;m not sure having =
something that looks like a template argument but completely isn&#39;t woul=
d be a good idea, though.</div><div><br></div><div>At least parts of this c=
ould be done as a library if it was possible to define templates in lambdas=
, thinking about how I could hack my way around that.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 7 December=
 2012 05:53, Shakti Misra <span dir=3D"ltr">&lt;<a href=3D"mailto:shakti.mi=
sra.works@gmail.com" target=3D"_blank">shakti.misra.works@gmail.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">@viboes: This is interesting at least from a=
 user point of view. May it will be=20
good to work on a library and post it here. If you need any help let me=20
know. Is it something like Metaparse proposed for boost?<br><br>On Thursday=
, November 29, 2012 4:47:20 AM UTC+5:30, viboes wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">
Le 27/11/12 15:49, Anton Golov a =EF=BF=BDcrit :
<br><div><div class=3D"h5">&gt; I&#39;ve been thinking about how pattern-ma=
tching of types could
<br>&gt; be done in expressions, as opposed to only in template
<br>&gt; specialisation definitions. =A0These are more assorted ideas
<br>&gt; than a well-formed proposal; I do not possess the
<br>&gt; understanding to determine whether this is implementable or
<br>&gt; not.
<br>&gt;
<br>&gt; The most basic form is
<br>&gt;
<br>&gt; =A0 =A0 X[PARAMS][PATTERN]
<br>&gt;
<br>&gt; which, in a boolean context, expands to match&lt;X&gt;::value
<br>&gt; where
<br>&gt;
<br>&gt; =A0 =A0 template&lt;typename&gt;
<br>&gt; =A0 =A0 struct match : std::false_type {};
<br>&gt;
<br>&gt; =A0 =A0 template&lt;PARAMS&gt;
<br>&gt; =A0 =A0 struct match&lt;PATTERN&gt; : std::true_type {};
<br>&gt;
<br>&gt; Example usages:
<br>&gt;
<br>&gt; A replacement for std::is_const:
<br>&gt;
<br>&gt; =A0 =A0 X[typename T][T const]
<br>&gt;
<br>&gt; Matching an array of any size, of a given type:
<br>&gt;
<br>&gt; =A0 =A0 X[size_t N][array&lt;int, N&gt;]
<br>&gt;
<br>&gt; A replacement for std::is_same:
<br>&gt;
<br>&gt; =A0 =A0 X[][Y]
<br>&gt;
<br>&gt;
<br>&gt;
<br>Hi,
<br>
<br>We could use the current syntax. With C++ we could define a template=20
<br>match that could allow you to check
<br>
<br>A replacement for std::is_const:
<br>
<br>=A0 =A0match&lt;_T const, X&gt;
<br>
<br>where _T is a pattern variable
<br>
<br>Matching an array of any size, of a given type:
<br>
<br>=A0 =A0match&lt;_array_&lt;int, _N&gt;, X&gt;
<br>
<br>where _array_ is and artificial template accepting pattern variables,=
=20
<br>even those representing non-type parameters
<br>
<br>A replacement for std::is_same:
<br>
<br>=A0 =A0match&lt;Y, X&gt;
<br>
<br>A extract meta-function could be defined in the same way and allows to
<br>
<br>The main problem is that defining this template is cumbersome. Of cours=
e=20
<br>the compiler could use other techniques to check if there is a match an=
d=20
<br>get rid of the _array_ trick.
<br>
<br>extract&lt;_T &amp;, _T, X&gt;
<br>
<br>instead of
<br>
<br>remove_reference&lt;X&gt;
<br>
<br>The question is which is the added value. Will the end-user understand=
=20
<br>better pattern matching than specific meta-functions?
<br>Which meta-programming style will result with this addition and how=20
<br>could it be better.
<br>
<br>=A0 Why not define specific templates to that match the specific patter=
n
<br>
<br>template &lt;typename ARRAY&gt;
<br>struct do_something;
<br>
<br>template &lt;typename T, size_t N&gt;
<br>struct do_something&lt;array&lt;T,N&gt;&gt; {...};
<br>
<br>do_something&lt;X&gt;
<br>
<br>-- Vicente
<br>
<br>P.S. If there is an interest, I could share privately the ideas on how=
=20
<br>the match and extract templates could be implemented as a library on=20
<br>C++11 (not checked with a compiler yet). Note that the design doesn&#39=
;t=20
<br>scales well and needs a lot of specificities from each specific class=
=20
<br>template.
<br>
<br></div></div></blockquote>

<p></p>

-- <br>
=A0<br>
=A0<br>
=A0<br>
</blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--0016e6de044514510304d03f0f96--

.

Le 07/12/12 05:53, Shakti Misra a =E9crit :
> @viboes: This is interesting at least from a user point of view. May=20
> it will be good to work on a library and post it here. If you need any=20
> help let me know.=20
As I said the library approach doesn't scales. You need to specialize=20
the match and extract functions for any new template. I would however=20
try to compile what I have in mind and I will show it here if it works ;-)
> Is it something like Metaparse proposed for boost?
No. metaparse is a lexical parser which is much more complex than the=20
match/extract have in mind which are based on pattern-matching for C++=20
types.

Vicente

--=20




.