Uniform syntax for templates (second try)

[Marcin Kuszczak]

Andrei Alexandrescu wrote:

> Marcin Kuszczak wrote:
>> As general comment I would like to notice that I am not considering this
>> syntax as finished work. There might be some changes in it, and I even
>> don't care too much about all details which should be adjusted. In my
>> opinion major advantages of this proposal are:
>> 
>> 1. Same syntax for practically every compile time expression in D. You
>> have to learn it only once and then intuitively you will apply same
>> pattern in every case. Currently you have to learn by heart the whole
>> IsExpression table and additionally syntax for template functions. E.g.
>> matching static arrays, is far from intuitive, and even I would say that
>> it is against good practices of programming which demands that symbols
>> are defined *before* usage, not after.
> 
> Uniformity is good.
> 
>> 2. Dropping redundant IsExpression for templates. This makes a lot of
>> code easier to read (e.g. because of less parenthesis). The notation gets
>> also shorter.
> 
> I think this is rather minor.

IsExpression is causing problems for newbies, as I already mentioned before.
Is syntax for templates was mentioned as difficult for students of D
language. And it must be learnt by heart. (Well, maybe that's opposite:
template function parameters must be learnt by heart, as they are
inconsistent with is()?)
 
>> 3. My proposal is more flexible & extensible than current syntax(-es).
>> It's also shorter in general case. And adding additional possibilities to
>> this compile time expression will allow to use them in all compile time
>> statements, differently than it is now.
> 
> I'm not sure about terseness. Your patterns tend to introduce more
> symbols.

You will need more symbols only when you need to take more information from
expression. There will be always version which will introduce not more
symbols than currently.

>> 4. It seems additionally that better pattern matching will render
>> redundant many use cases for if(ct_expression).
> 
> Yah, that I'm looking forward to.
> 
> This is a big change. To sell this big change to people and Walter, you
> need to have some smashing advantages. So far you have I'm not seeing a
> smashing advantage. Easily decomposing types in patterns would be one,
> but that is something that could be pulled out of your proposal and
> implemented alone.

Well, I am not saying that this is top-priority change right now. I am just
saying that it would be better to have it implemented - it should be a way
to go. I really don't have an idea how much work is it to implement this.
The fact is that most pieces are already in-place, they just have to be
connected together. Maybe it would be possible to introduce this change
partially, finally depreciating is() completely? There will be probably not
so much impact on user code, as only heavily templated code (using matching
by e.g. static arrays) will be affected. Common cases will stay exactly the
same.

-- 
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/
-------------------------------------