Is there a way to convert a string to a struct, similarly to the conversion of a struct to a custom string representation ?

The following code works fine when using format("%s",C) or to!string(C):

    struct sCustomConv
    {
        string toString()
        {
            return "My custom representation";
        }
    }

    sCustomConv C;
    string MyBackup = to!string(C);

But I can't find which class operator must be overloaded (or more simply how-to) to make this possible:

    C = to!sCustomConv(MyBackup);

Thx.

On Friday, August 02, 2013 06:50:01 Douglas Petterson wrote:
> Is there a way to convert a string to a struct, similarly to the conversion of a struct to a custom string representation ?
> 
> The following code works fine when using format("%s",C) or
> to!string(C):
> 
>      struct sCustomConv
>      {
>          string toString()
>          {
>              return "My custom representation";
>          }
>      }
> 
>      sCustomConv C;
>      string MyBackup = to!string(C);
> 
> But I can't find which class operator must be overloaded (or more simply how-to) to make this possible:
> 
>      C = to!sCustomConv(MyBackup);

http://stackoverflow.com/questions/8351245/override-tot-for-used-defined-t-in-d

- Jonathan M Davis

On Friday, 2 August 2013 at 05:09:14 UTC, Jonathan M Davis wrote:
> On Friday, August 02, 2013 06:50:01 Douglas Petterson wrote:
>> Is there a way to convert a string to a struct, similarly to the
>> conversion of a struct to a custom string representation ?
>> 
>> The following code works fine when using format("%s",C) or
>> to!string(C):
>> 
>>      struct sCustomConv
>>      {
>>          string toString()
>>          {
>>              return "My custom representation";
>>          }
>>      }
>> 
>>      sCustomConv C;
>>      string MyBackup = to!string(C);
>> 
>> But I can't find which class operator must be overloaded (or more
>> simply how-to) to make this possible:
>> 
>>      C = to!sCustomConv(MyBackup);
>
> http://stackoverflow.com/questions/8351245/override-tot-for-used-defined-t-in-d
>
> - Jonathan M Davis

There was a request for enhancement to provide a "fromString" for arbitrary types. The idea is that once we have that, then functions such as parse or to!S(string) will be generic, and work on mostly anything. Unfortunatly, (AFAIK), nobody is working on this.

Here is a discussion I opened:
http://forum.dlang.org/thread/gzodptjyzpqnhxctbbuv@forum.dlang.org

...and I just noticed it ends with me saying "I'll try to write a DIP then :)" and then not doing it :/

On Friday, 2 August 2013 at 05:09:14 UTC, Jonathan M Davis wrote:
> On Friday, August 02, 2013 06:50:01 Douglas Petterson wrote:
>> Is there a way to convert a string to a struct, similarly to the
>> conversion of a struct to a custom string representation ?
>> 
>> The following code works fine when using format("%s",C) or
>> to!string(C):
>> 
>>      struct sCustomConv
>>      {
>>          string toString()
>>          {
>>              return "My custom representation";
>>          }
>>      }
>> 
>>      sCustomConv C;
>>      string MyBackup = to!string(C);
>> 
>> But I can't find which class operator must be overloaded (or more
>> simply how-to) to make this possible:
>> 
>>      C = to!sCustomConv(MyBackup);
>
> http://stackoverflow.com/questions/8351245/override-tot-for-used-defined-t-in-d
>
> - Jonathan M Davis

That perfectly fits to my need, thx.

On Friday, August 02, 2013 08:40:51 monarch_dodra wrote:
> There was a request for enhancement to provide a "fromString" for arbitrary types. The idea is that once we have that, then functions such as parse or to!S(string) will be generic, and work on mostly anything. Unfortunatly, (AFAIK), nobody is working on this.
> 
> Here is a discussion I opened: http://forum.dlang.org/thread/gzodptjyzpqnhxctbbuv@forum.dlang.org
> 
> ...and I just noticed it ends with me saying "I'll try to write a DIP then :)" and then not doing it :/

What's the point of fromString when a constructor will do the job just fine?

- Jonathan M Davis

On Friday, 2 August 2013 at 07:59:59 UTC, Jonathan M Davis wrote:
> On Friday, August 02, 2013 08:40:51 monarch_dodra wrote:
>> There was a request for enhancement to provide a "fromString" for
>> arbitrary types. The idea is that once we have that, then
>> functions such as parse or to!S(string) will be generic, and work
>> on mostly anything. Unfortunatly, (AFAIK), nobody is working on
>> this.
>> 
>> Here is a discussion I opened:
>> http://forum.dlang.org/thread/gzodptjyzpqnhxctbbuv@forum.dlang.org
>> 
>> ...and I just noticed it ends with me saying "I'll try to write a
>> DIP then :)" and then not doing it :/
>
> What's the point of fromString when a constructor will do the job just fine?
>
> - Jonathan M Davis

Really? Because it's not generic. Unless I'm missing something, I'm sure you can appreciate that the goal is to allow:

to!S("string")
or
myFile.readf("Entry: %s", &s);

And a simple constructor doesn't (*CAN'T*) allow that.

On Friday, August 02, 2013 10:35:22 monarch_dodra wrote:
> On Friday, 2 August 2013 at 07:59:59 UTC, Jonathan M Davis wrote:
> > On Friday, August 02, 2013 08:40:51 monarch_dodra wrote:
> >> There was a request for enhancement to provide a "fromString"
> >> for
> >> arbitrary types. The idea is that once we have that, then
> >> functions such as parse or to!S(string) will be generic, and
> >> work
> >> on mostly anything. Unfortunatly, (AFAIK), nobody is working on
> >> this.
> >> 
> >> Here is a discussion I opened: http://forum.dlang.org/thread/gzodptjyzpqnhxctbbuv@forum.dlang.org
> >> 
> >> ...and I just noticed it ends with me saying "I'll try to
> >> write a
> >> DIP then :)" and then not doing it :/
> > 
> > What's the point of fromString when a constructor will do the job just fine?
> > 
> > - Jonathan M Davis
> 
> Really? Because it's not generic. Unless I'm missing something, I'm sure you can appreciate that the goal is to allow:
> 
> to!S("string")

As long as S defines a constructor which takes a string, this works just fine. All fromString would be doing would be to declare a function which did the same thing as the constructor.

> or
> myFile.readf("Entry: %s", &s);
> 
> And a simple constructor doesn't (*CAN'T*) allow that.

Really? All it would have to do wolud be to pass the string that is the user input into the constructor for typeof(s) and set s to that.

- Jonathan M Davis

On Friday, 2 August 2013 at 09:11:26 UTC, Jonathan M Davis wrote:
> On Friday, August 02, 2013 10:35:22 monarch_dodra wrote:
>> On Friday, 2 August 2013 at 07:59:59 UTC, Jonathan M Davis wrote:
>> > On Friday, August 02, 2013 08:40:51 monarch_dodra wrote:
>> >> There was a request for enhancement to provide a "fromString"
>> >> for
>> >> arbitrary types. The idea is that once we have that, then
>> >> functions such as parse or to!S(string) will be generic, and
>> >> work
>> >> on mostly anything. Unfortunatly, (AFAIK), nobody is working on
>> >> this.
>> >> 
>> >> Here is a discussion I opened:
>> >> http://forum.dlang.org/thread/gzodptjyzpqnhxctbbuv@forum.dlang.org
>> >> 
>> >> ...and I just noticed it ends with me saying "I'll try to
>> >> write a
>> >> DIP then :)" and then not doing it :/
>> > 
>> > What's the point of fromString when a constructor will do the
>> > job just fine?
>> > 
>> > - Jonathan M Davis
>> 
>> Really? Because it's not generic. Unless I'm missing something,
>> I'm sure you can appreciate that the goal is to allow:
>> 
>> to!S("string")
>
> As long as S defines a constructor which takes a string, this works just fine.
> All fromString would be doing would be to declare a function which did the
> same thing as the constructor.

Right. That's what to! does. In that case, I'll correct myself, and say:

parse!S("string")

wouldn't work.

>> or
>> myFile.readf("Entry: %s", &s);
>> 
>> And a simple constructor doesn't (*CAN'T*) allow that.
>
> Really? All it would have to do wolud be to pass the string that is the user
> input into the constructor for typeof(s) and set s to that.
>
> - Jonathan M Davis

It wouldn't because "myFile.readf("Entry: %s %s", &s, &s);" wouldn't know *what* to pass to the constructor. AFAIK. I could be wrong.

Regardless, a constructor can only be explicit, whereas a generic "fromString" can be implemented by default for structs, just the same way you don't ask users to write a toString.

Given:

struct Person
{
  string name;
}

Then:
parse!Person(`Person("Jonathan")`);
Should "just work".

Finally, a constructor is meant to construct an object, and not unserialize it. There could be notable differences in both.

auto myName = to!Person("Jonathan"); //Fine
parse!Person(`Person("Jonathan")`);

As you can see, the strings don't match. A constructor may not be the reciprocal of toString. You simply *can't* call a constructor in a parse operation.

At a first sight the idea of having a standard fromString seems good.

I think Haskell has something similar, the standard Read typeclass:

http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html#t:Read

Bye,
bearophile

On Friday, 2 August 2013 at 09:59:12 UTC, monarch_dodra wrote:
> It wouldn't because "myFile.readf("Entry: %s %s", &s, &s);" wouldn't know *what* to pass to the constructor. AFAIK. I could be wrong.

It should. Pattern matching is not target-aware for readf patterns. It will simply find a whitespace separators and pass everything to the left to one constructor and everything to the right to the second one (trimming extra whitespaces).