• Marcin Kuszczak (94/94) Jan 12 2008 Hello!

Marcin Kuszczak <aarti_please_no spam_interia.pl> writes:

Hello!

I wonder if you ever try to define something like this:

void parse(T : T == char[] || T == wchar[] || T == dchar[])(T str) {
}

or match associative array in template declaration?

Or maybe you got annoyed with different syntaxes for template definitions
and is() expression? 

static if (is(T : U[N], U, size_t N)) ...; //ok
void parse(T : U[N], U, size_t N) ...; //doesn't work
void parse(T U: U*)(T val) {}; //doesn't work

or wonder why symbol T gets redefined into array element like below:
void parse(T : T[]) {}

or wants to define template like below:
void parse(T : isString!(T)) {}

If yes, please read on.

I will propose few simple modification for current syntax. They are not
completely new, but rather based on current design with some (quite
obvious) extensions and improvements. I don't know what is Walter & Andrei
cooking for us in future, so maybe solution is already prepared (as
according to docs from conference pattern matching should work also for
macros). But nevertheless I think it will be good to share with you these
ideas. If it would be implemented it is also argument against enum as
manifest constant identifier in favour of alias.

-----------------

Proposed syntax:

ctexpr:   T [S1[=type] S2[=type] ... Sn[=type]] [: inexpr];
inexpr:   pattern | pattern ctexpr | ctexpr
pattern: type | derived data type; // previously defined symbols 
                                   // S can be used here
                     
1. ctexpr and pattern (when there is a match) evaluates to true or false

2. both pattern and ctexpr must be true

3. symbols in pattern are substituted with concrete types when evaluating
ctexpr

4. symbols can have fixed types (e.g S1=int). If reasonable when evaluating
pattern symbols can have also value:
e.g T U N=uint : U[N] N>100; // matches all static arrays bigger than 100; 
                             // N = number of declared elements in s. array

5. parts of ctexpr can be omitted, so it looks exactly like current
declarations (mostly)
e.g. T : bool; // omitted symbols and ctexpr
     T;        // omitted symbols, ":", pattern, ctexpr

6. initial T can not be redefined; currently it is rather confusing that
elephant transforms into monkey in following:
void parse(T : T[]) {}

7. following definition:
void parse(T ELEM : ELEM[], U : bool, V SA N=uint : SA[N] N>100) {}
 should be just syntactic sugar for:
void parse(is(T ELEM : ELEM[]) && is(U : bool) && is(V SA N=uint : SA[N]
N>100)) {}
Don't worry about long function template definition - above example is for
extreme hard core metaprogrammers! Proposed syntax is no longer than
current one - it just extends possibilities.

8. ... eventually is() for metaprogramming could be dropped.

9. it is an error if defined symbols are not used in inexpr or don't have
assigned types in ctexpr

10. if inexpr is not defined T is aliased to all symbols

Well, I probably missed something here, but IMHO it is just a matter of
refining of this proposal... :-)

-----------------

With above proposal there would be only one syntax for:
is(), static if, template definition & static assert

I think that there is also often need in metaprogramming just to decompose
type without using value of expression at all. Currently decomposition is
possible only in is() and in template declaration (somewhere else?...).

To get advantage of type decomposition without using is() and template
declaration I propose to use alias.

Alias could have EXACTLY same syntax as for other meta constructs without
breaking current behaviour. How is it possible? See below:

alias T U N=uint: U[N] N>100;

1. if ctexpr in alias evaluates to false compilation is stopped with error
message.

2. currently we have only 
alias T U;
which means T is aliased as U

3. in extended alias definition you would be able to define few symbols
instead of one which not necessarily are same as original T.

4. current syntax is just subpattern of new syntax

-----------------

Why my proposal is argument for using alias instead of enum for manifest
constants? See following:

alias T U N=uint: U[N] N>100;

here type T is decomposed into:
U - static array element type
N - number of elements in static array

In this example N is just *** manifest constant *** for uint value.

IMHO it's good argument to use alias keyword for manifest constants.

-- 
Regards
Marcin Kuszczak (Aarti_pl)
-------------------------------------
Ask me why I believe in Jesus - http://www.zapytajmnie.com (en/pl)
Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/
-------------------------------------