Extending readf?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Feb 7 08:03:05 PST 2013


On Thu, Feb 07, 2013 at 02:27:12PM +0100, monarch_dodra wrote:
> Not so long ago, there was an amazing article about how user defined
> types and formated writes behaved:
> 
> http://wiki.dlang.org/Defining_custom_print_format_specifiers
> 
> As cool as it is, I was writting a little user defined type, and I
> wanted to the the contrary: un-format it to read it.
> 
> Apparently. You can't do it. I'm not talking about "you can't
> customize it", I mean "you can't do it, at all."
> 
> For all the bashing C++'s ">>" and "<<" operators get, they at least
> work both ways for UDTs.
> 
> I found this thread:
> http://forum.dlang.org/thread/mailman.2107.1335304266.4860.digitalmars-d-learn@puremagic.com
> And the forked thread:
> http://forum.dlang.org/thread/20120424215103.GA28525@quickfur.ath.cx
> 
> Which basically amounts to "Maybe do you want to open this
> discussion in the main D newsgroup?" and the suggestion "Does it
> make sense to add a fromString() method to user-defined types for
> this? D's toString support is awesome (you can basically call
> to!string on just about anything and it works). It would be nice to
> have similar support for the reverse operation." To which no one
> added anything.
> 
> That was in .learn, so it might not have gotten much coverage.

+1.

Using a similar design to the way Format() works, we can make fromString
such that the format specifier gets passed to the user-defined type,
complete with all information like field width, precision, etc., that it
can use to correctly parse the input. The input itself, of course,
will be in the form of an input range. At the very least, this should be
how it works under the hood.

Once that is working, we can build more convenient interface on top of
it, such as "simplified" fromString methods that gets called when a
default format specifier (probably %s) is used, and the user-defined
type doesn't want to bother with dealing with the nitty-gritty details
of format specifiers.


> How complicated wold it be to have things specify a "fromString"
> method? Is it worth the effort?

Yes.


> Is it possible to have a "fromString" default generated? If not,
> would it be OK if formatted read could work for only on things that
> define "fromString"?

I see fromString as the dual operation to toString. So I'd say, if the
default toString for a particular type is non-reversible, then there's
no need to make the reverse work as well. For example, class objects'
default toString just prints the class name. That's non-reversible,
because there's no way to specify ctor arguments in the format string or
current object state, etc., even if you wanted to. So there's probably
no need to have a default class fromString.

But all POD types should have a default fromString (structs, for
example, will be formatted with default values, so it's reversible).


> In any case, it feels like a pretty wide hole in regards to a high
> level statically typed language.

So let's fill that hole. :)


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy


More information about the Digitalmars-d mailing list