First of all I found new additions to Phobos really great! Thanks! I would like to suggest here some extensions which could be useful: 1. parse() function does not allow to apply additional, user defined transformations on consumed tokens. I mean for example additional checking for matching parsed token to regular expression pattern. It would be probably better to have just template function consume(T)() which returns consumed token of specific type as string. Then it would be possible to convert consumed token with to!(T) template. I see here 2 possibilities: replace parse with consume or add additional template consume. 2. Conversion function template to!(T)() works great. It can even convert arrays into string. Unfortunately the other way (converting from string into array) is not possible, although I think it should. If it work properly it would allow easy serialization of complex types. If request would be applied, then probably it would be necessary to change representation of strings in serialized form to use "" or ''. (See also next point.) 3. String parsing functions. It seems to be quite common task to parse delimited with "" or '' strings from text. I think that in case of such delimited strings there should be also escape characters supported, so e.g. when in delimited string there is \" it should be properly interpreted as character, not as delimiter. (BTW. Conversion to/from escape characters is also quite common, so some functions in standard library would be great also.). I think that quite a good solution would be to allow 3 forms for strings: delimited with ", delimited with ' and without delimiters. In 3rd case there should be no conversion for escape characters. 4. It should be possible to add custom parsers and converters. It will allow full serialization solution on compile time. In my library Doost/ProgramOptions I can not use much of new functionality directly because of above problems.
1. parse() is meant to use known-in-advance data formats; a function closer to what you mention is string.munch. An obvious addition will be to allow munch with a regex, which is exactly what you mention. 2. to!(T) also has a more limited charter. Converting strings to arrays was not considered appropriate for implementing at this level because there are so many options (e.g., having the size prefix the string, various quoting mechanisms etc.) that any particular design would have been too constraining. Some higher-level, more abstract serialization ideas would be welcome. to!(T) does not seem like the right level. 3. A Perl-like quotemeta function does indeed belong to the standard library (probably in the string module though). 4. This is a bit vague. Adding a full-blown serialization solution is worthwhile, but it will take some time. The to!(T) and parse!(T) families of functions are only meant as backends for such a framework, not parts of its architecture.
The current range facilities seem to obsolete this. Feel free to reopen if there are unfulfilled requirements.