Builtin regex (Was: How to complex switch?)

[Timon Gehr]

> Stewart Gordon:
>
> > I think D is going the right way on the whole by leaving regexps to a library.
 Though
> > this does limit such possibilities as optimised regexp switches.
>
> Leaving regexps to a library is an acceptable choice for D, or maybe even the
best choice. In D even associative arrays are not so important as builtins, you
just need literals for associative arrays.

> On the other hand my experience shows me some other things are better as
builtins (or partial built-ins), as tuples. I'd like unpacking syntax sugar for
tuples, to be used inside foreach too, and as recently emerged in D.learn, some
better cast for tuples (to allow conversion of slightly differently typed tuples,
and structural typing).

> Tuples are a general language construct, useful in many situations for many
different purposes, they are _much_ more commonly useful than regex. I use some
regex most Python > scripts that processes lot of text, but I use tuples every 4-5
lines of code or less :-) And indeed, in Python too regexes are not built-in,
while tuples are.
>
> Bye,
> bearophile

Tuple literals would indeed be very nice. This _would_ mean that tuples get
entirely built-in (having syntactic sugar for phobos functionality in the language
seems like a very bad design to me, it would at least have to be copied/moved to
druntime).

However, tuple literals break the comma operator...

But who would write something like
?
auto t=(1,2,3);

anyway in serious code? (where "," means comma operator).

Therefore Tuple literals could be introduced by a minor change in the grammar,
where uses of the comma operator like

return a=2,b=3; would still work normally.

What would be the type of such a tuple literal? (T,T,T,...)?

I don't expect something like this to be implemented soon though.

Timon