[Issue 1827] Uniform syntax for is(), static if, alias, template definition & static assert

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1827





------- Comment #2 from aarti at interia.pl  2008-02-12 05:26 -------
(In reply to comment #1)
> Where was the proposal?

I posted it on digitalmars.D. But it was early Sunday morning (at least in
Europe), so probably everyone was too sleepy to read this lengthy post :-)

>> 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
>I think the intent is that at least the first two work.

Matching in template function pointers can be also useful sometimes. I just
finished serialization library for D
(http://dsource.org/projects/doost/browser/trunk/doost/util/serializer)
and I had to deal sometimes with very exotic types.

I found e.g. that there is no way to create pointer to class on heap in D.
(see: http://d.puremagic.com/issues/show_bug.cgi?id=1778)
I think that it would be possible to overcome this problem, but I must find a
little bit more time to rethink it. You can find my initial thoughts in bug
report...

> I think the proposal has good merit. I like the separation between introduced
> types and constraints. The separation is diminished by the presence of =T
> constraints on the left-hand side of ":". 

Well maybe it would be even better to put =T on right side of ":". E.g. like
this:
T E K : E[K=uint] 
I have not clear opinion on that. Both versions have their pros & cons.

> The syntax we had in mind, that would also apply to templates, is(), etc., is:

> T if condition

> where "condition" is a compile-time expression that must evaluate to true if T
> is to be matched. Then you'd write:
> S toupper(S if isSomeString!(S))(S input) { ... }

Drawback of this syntax is that it will completely break source compatibility.
Using ":" as separator
and defining symbols before ":" will allow to keep quite a lot of code
completely unchanged. Given the fact that
proposed syntax can be reduced to simpler versions, it should match a lot of
current syntax e.g.
void parse(T); void parse(T : int); is(T U : U*); is(T E : E[])

-----

I am very curious what do you think about my 'alias' part of proposal? I found
a few places in my code where I wanted just to decompose type without checking
condition (condition was already checked before). But it is currently not
possible...

And what do you think about 'alias' as a way to define manifest constant? 

Initially I liked most 'alias', then when Walter decided to use 'enum' I
thought: "Ok. Enum is not so bad, as enums are definitely too simplistic for
higher level language.". But now, when I discovered the case with static array,
where N should be defined as unsigned integer value, I think that alias is much
better for that purpose. And 'enum' can be extended in better ways with other
features...


--