Uniform syntax for templates (second try)

[Marcin Kuszczak]

Andrei Alexandrescu wrote:

> Marcin Kuszczak wrote:
>> 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.
> 
> Why are you sure deprecating is() is a goal in and of itself? You
> mention beginners are having trouble understanding it, but then you'd
> need to make a pretty good case that beginners won't have much trouble
> understanding your way. (It took me a while.)

They will have to learn my syntax anyway. Currently there is no way around,
as my syntax is based on is() expression from D1.0. But in my proposal
there is only one syntax to learn. Currently you have to learn how to write
is() expression and how to write template function parameters.
 
> Besides one good thing about is() is that it allows you to match type
> patterns without error. 

It will be still possible as in your example below, but in simpler way:
static if (T V K :V[K])
I am not arguing about removing this case. It is usefull.

> For example: 
> 
> static if (is(T = V[K], K, V)) {
>      // T is a hash, use K and V
> } else static if (is(T = V[], V)) {
>      // T is an array, use V
> } ...

LOL. And now you have been stroked by D template syntax nuances! 

Above code is incorrect. And it is not only matter of '=' instead '=='. It
is the matter of funky syntax, which doesn't keep any rules. In fact in 2.0
it's even worse than in 1.0 after adding TemplateParameterList to is()
expression.

Above code should be written as below:

void main() {
    alias long[char[]] T;
    static if (is(T V == V[K], K)) {
        pragma(msg, V.stringof ~ " " ~ K.stringof);
    } else static if (is(T V == V[])) {
        pragma(msg, V.stringof);
    }
}

Who will guess how to write above without looking into docs? No one.

BTW. first pragma prints: "long const(char)[]". Is it by design or is it an
error?

> In contrast, aliasing can only fail with a compile-time error:
> 
> alias T K V : T = V[K];

This syntax would be usefull only in case where you can know for sure that T
is associative array. In such a case you can safely decompose T into
subtypes.

> I agree that using a symbol before clarifying that it's being introduced
> is odd. Anyhow, it would be great if more people added to this exchange
> to get a feel of the level of interest.
 
Well, I wonder why no one except you commented about this issue. That might
be the case that people didn't write so much code using isExpression and
complicated template function's template parameters. I have written
automatic serializer, which is currently probably the most advanced
solution for D. It has definable back-ends (SimpleText, JSon and
Binary(thanks to Bill Baxter, who wrote it)), versioning of classes,
importing old versions, thread safety, exception safety, discovering of
templated functions in user classes and optional saving results to string
or any other stream (btw. I would be happy to discuss with someone about my
design :-)). It is heavily templated code, with many different corner cases
which stresses type system a lot (e.g. I discovered that it's not possible
to create pointer to class in straight way). Maybe only few people wrote
such a code? I don't know because inconstancy just strikes in the eyes when
working with it...

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