Builtin regex (Was: How to complex switch?)

[Andrei Alexandrescu]

On 5/18/11 5:12 PM, Timon Gehr wrote:
>> Timon Gehr:
>>
>>> Library code should make use of the language to implement its semantics.
>>> Not the other way round.
>>
>> Why?
>
> Short story: Obvious?
>
> Do you really want to make some non-built-in types more equal than others? Why
> would you want to have a dependency cycle between std and the compiler?
>
> Longer story: You get all the drawbacks of a library-based solution except literal
> syntax (a one-character alias for tuple can already make up much of it without
> work from the compiler so your benefit is basically zero).
>
> But you want improved return type deduction, many will want tuple assignments in
> the style (a,b)=(b-a,a+b), etc. tuple cannot do it. Therefore the part the
> compiler takes will get so large that in the end the only relict of the library
> stuff will be that you have to import std.typecons; or else you will get some
> strange errors that do not at all look like your code. (Or even more silly, the
> compiler will directly nag you "Did you forget to import std.typecons?"). The
> question is, do you want to import typecons or not. It is just that and
> furthermore a question of clean design.
>
> How tuples are handled internally should be a compiler/runtime thing, not a
> standard library thing. I would be fine with Tuple!(T) defining conversions from
> and to the built-in tuple.
>
>>
>>
>>> Another reason I dislike it: it looks different to other "tuple literals"
>>> that are already built-in:
>>>
>>> foo (note, how, this, is, a, tuple, "!");
>>
>> Looking different from the built-in ones was the point of it, to avoid clashes.
>
> No. There is no way it could clash with foo (a,b,c).
>
> The only use case where the straightforward solution would clash is something like
> this:
>
> auto a=(i++,j++,k++);
>
> Nobody who is sane writes such code!
>
>>
>>
>>> Still, I think (|1,2,3|) is not optimal.
>>
>> Please, invent better things :-)
>
> 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.

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

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

Ehm.

Andrei