Builtin regex (Was: How to complex switch?)

[Timon Gehr]

Andrei Alexandrescu wrote:
> Timon Gehr wrote:
> >
> > 1. Deprecate using CommaExpression inside ParanthesizedExpression. (This does not
> > affect most code that uses the comma operator!)
> > 2. Wait a few releases.
> > 3. Introduce straightforward, built-in tuples:
> [snip]
>
> We've been thinking of this approach but it would be difficult to pull off.

How would it be difficult to realize? I guess there is literally no serious D code
out there that uses anything that could clash with tuple literals. (And if there
is any - it can easily be rewritten to use inline delegates instead...)

It should also be only a minor change in the grammar.

>
> One possibility that I hadn't thought before is to use ";" for
> separating tuple elements. Upon a casual inspection, it turns out no
> statement can be enclosed directly in "(" and ")" so there's no
> ambiguity. It would also take care of the issue "did you mean to pass
> them as function arguments, or as one tuple argument?" Just a thought...

other possibilites:

1. make tuple expansion explicit. //maybe not too great as the built-in TypeTuple
expands by default.
2. use the same convention as that used for one-element tuples.

void foo(int a,int b,int c);    //1
void foo((int,int,int) t,); //2

auto t=(1,2,3);
foo(t);  //calls 1 (since t is expanded)
foo(t,); //calls 2 (t is not expanded)

This would change the meaning of trailing "," when tuples are involved though.

>
> auto t=(1; "string"; 'c');

I have actually considered that too. Some issues:

1. ";" is not as easy to type as "," on many keyboard layouts. (not everybody will
use a US Keyboard)
2. It is, like "(|1,2,3|)" another syntax for the same thing that is already
present in the language, (template) parameter tuples. Furthermore, Array and
AssocArray both use "," as a delimiter, meaning it would add further
inconsistency. I think tuple literals should build up on existing features, not be
orthogonal to them. imho tuple literals are a logical consequence of generalizing
D's design, not an entirely new feature.
3. Most important: Error messages. If ";" is not guaranteed to be a statement
delimiter, writing a compiler that can generate meaningful error messages is
_much_ more difficult!

>
> Ehm.
>
> Andrei


Timon