> 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
