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.

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

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"?

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

On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:
> ...
> For all the bashing C++'s ">>" and "<<" operators get, they at least work both ways for UDTs.
>
> ...

I never understood why people like to bash about them.

I am yet to find a codebase in production where it is not obvious from context that streams are being used and not bit manipulation.

--
Paulo

On 2/7/13 8:47 AM, Paulo Pinto wrote:
> On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:
>> ...
>> For all the bashing C++'s ">>" and "<<" operators get, they at least
>> work both ways for UDTs.
>>
>> ...
>
> I never understood why people like to bash about them.
>
> I am yet to find a codebase in production where it is not obvious from
> context that streams are being used and not bit manipulation.

Syntax is the least of iostreams' problem.

Andrei

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

On Thursday, 7 February 2013 at 16:05:34 UTC, H. S. Teoh wrote:
>
> So let's fill that hole. :)
>
>
> T

I'll try to write a DIP then :)