digitalmars.D.bugs - [Issue 1630] New: Few suggestions for std.conv (D language 2.0)
- d-bugmail puremagic.com (41/41) Oct 31 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1630
- d-bugmail puremagic.com (18/18) Oct 31 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1630
- d-bugmail puremagic.com (10/10) Oct 11 2009 http://d.puremagic.com/issues/show_bug.cgi?id=1630
http://d.puremagic.com/issues/show_bug.cgi?id=1630 Summary: Few suggestions for std.conv (D language 2.0) Product: D Version: 2.006 Platform: PC OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: bugzilla digitalmars.com ReportedBy: aarti interia.pl 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. --
Oct 31 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1630 ------- Comment #1 from andrei metalanguage.com 2007-10-31 12:02 ------- 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. --
Oct 31 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1630 Andrei Alexandrescu <andrei metalanguage.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |andrei metalanguage.com AssignedTo|nobody puremagic.com |andrei metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 11 2009