We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places) that handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other mechanism. Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings. For std.conv I'm thinking
template fromString(T : int) {
T fromString(char[] str) {
return toInt(str);
}
}
template fromString(T : uint) {
T fromString(char[] str) {
return toUint(str);
}
}
... etc...
The date module could use a function instead of a template since there would be only 1 fromString in the module and so there's no need to use templates to specify the return type.
thoughts?
-Ben

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sc5n$25m8$1@digitaldaemon.com...> We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places) that handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other mechanism. Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings.
I should add an alternative is to add more toFoo's like toDouble, toFloat,
toDate, etc.
- I don't really mind either convention actually.

In article <d0sdv0$27io$1@digitaldaemon.com>, Ben Hinkle says...
>>>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message
>news:d0sc5n$25m8$1@digitaldaemon.com...>I should add an alternative is to add more toFoo's like toDouble, toFloat,
>toDate, etc.
>- I don't really mind either convention actually.
>
Ben: I recently passed some D code to Walter to fill in the blanks within
std.conv for string to real conversions. Functions like toFloat(), toDouble(),
toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
toIreal(), which hopefully if he has some time they'll be added in the near
future. But a toDate() and maybe even a toTime() conversion, sounds like a good
idea to add these functions to std.conv too! :)
David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Good idea.
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sdv0$27io$1@digitaldaemon.com...>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sc5n$25m8$1@digitaldaemon.com...> > We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places)
that
> > handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other
mechanism.
> > Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings.
>> I should add an alternative is to add more toFoo's like toDouble, toFloat,
> toDate, etc.
> - I don't really mind either convention actually.
>>>

> Ben: I recently passed some D code to Walter to fill in the blanks within
> std.conv for string to real conversions. Functions like toFloat(),
> toDouble(),
> toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
> toIreal(), which hopefully if he has some time they'll be added in the
> near
> future.
Cool. I hope it makes it in. Then we wouldn't need any fromString mumbo jumbo.
> But a toDate() and maybe even a toTime() conversion, sounds like a good
> idea to add these functions to std.conv too! :)
I think they would be better to be in the "natural" module std.date. Personally I'd even consider replacing the "parse" function in std.date since that is a pretty generic name. What were you thinking of for toTime? I haven't thought about it.

In article <d0sp83$2kcg$1@digitaldaemon.com>, Ben Hinkle says...
>>>> Ben: I recently passed some D code to Walter to fill in the blanks within
>> std.conv for string to real conversions. Functions like toFloat(),
>> toDouble(),
>> toReal(), toIfloat(), toIdouble(), toIreal(), toCfloat(), toCdouble(), and
>> toIreal(), which hopefully if he has some time they'll be added in the
>> near
>> future.
>>Cool. I hope it makes it in. Then we wouldn't need any fromString mumbo jumbo.
>>> But a toDate() and maybe even a toTime() conversion, sounds like a good
>> idea to add these functions to std.conv too! :)
>>I think they would be better to be in the "natural" module std.date. Personally I'd even consider replacing the "parse" function in std.date since that is a pretty generic name. What were you thinking of for toTime? I haven't thought about it.
>
*knocks head* Yeah you're right! My mistake, toDate() would go into std.date
duh! :) And about the toTime() function, I was thinking that it and toDate()
would make more sense as wrappers around parse() instead of using it directly.
But now that I think about it, Walter added a couple of functions like "char[]
toTimeString(d_time time)," "d_time toDtime(DosFiletime time)," and "d_time
toUTCString(d_time time) back in the dmd v0.111 build. Which he also fixed a
parse() problem in handling years < 1970 correctly, at the time I was having
problems with this bug while writing some simple date functions for a
sub-project on my website.
David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Well, er, the obvious fly in this ointment is that we don't overload on return type, which would confine the entire set of fromString() functions to template ones (for which the language currently requires explicit instantiation).
This prevents non-template ones, and also ignores the possibility of future (albiet limited) implicit instantiation, that Walter's hinted at from time to time (and that many have asked for).
So, I think it's not a flyer.
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sc5n$25m8$1@digitaldaemon.com...> We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places) that handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other mechanism. Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings. For std.conv I'm thinking
>> template fromString(T : int) {
> T fromString(char[] str) {
> return toInt(str);
> }
> }
> template fromString(T : uint) {
> T fromString(char[] str) {
> return toUint(str);
> }
> }
> ... etc...
>> The date module could use a function instead of a template since there would be only 1 fromString in the module and so there's no need to use templates to specify the return type.
>> thoughts?
> -Ben
>>

:-)
This is exactly why the mango.format package is the way it is;
In article <d0t05i$2rqv$1@digitaldaemon.com>, Matthew says...
>>Well, er, the obvious fly in this ointment is that we don't overload on return type, which would confine the entire set of fromString() functions to template ones (for which the language currently requires explicit instantiation).
>>This prevents non-template ones, and also ignores the possibility of future (albiet limited) implicit instantiation, that Walter's hinted at from time to time (and that many have asked for).
>>So, I think it's not a flyer.
>>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sc5n$25m8$1@digitaldaemon.com...>> We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places) that handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other mechanism. Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings. For std.conv I'm thinking
>>>> template fromString(T : int) {
>> T fromString(char[] str) {
>> return toInt(str);
>> }
>> }
>> template fromString(T : uint) {
>> T fromString(char[] str) {
>> return toUint(str);
>> }
>> }
>> ... etc...
>>>> The date module could use a function instead of a template since there would be only 1 fromString in the module and so there's no need to use templates to specify the return type.
>>>> thoughts?
>> -Ben
>>>> >>

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0t05i$2rqv$1@digitaldaemon.com...> Well, er, the obvious fly in this ointment is that we don't overload on return type, which would confine the entire set of fromString() functions to template ones (for which the language currently requires explicit instantiation).
Yeah - it would be pretty clunky. There isn't that much difference between toInt(str) and fromString!(int)(str) aside from the ability to have "int" a template parameter. Plus with name lookup rules one would probably have to write out tons of package and module names so it would get more and more verbose. yuck.
> This prevents non-template ones, and also ignores the possibility of future (albiet limited) implicit instantiation, that Walter's hinted at from time to time (and that many have asked for).
I was thinking the non-template ones would use name lookup rules to find the right ones. But that's still pretty verbose.
> So, I think it's not a flyer.
The toDouble etc solution is better. My goal was to have something consistent so that is fine - even though it includes the type in the name.

Hi, Ben
I am using two forms:
bool fromString(in string token, out T value)
bool fromString(in string token, out T value, in T defaultValue)
both of them return true if conversion were successfull.
I've found that blind forms like
T fromString(in str token)
are not useful in most cases if they are not generating exceptions.
And also signatures like
bool fromString(in str token, out T value)
do not need to be templates.
Andrew Fedoniouk.
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0sc5n$25m8$1@digitaldaemon.com...> We have toString as the mechanism to convert types to char[]. How about adding fromString templates/functions to std.conv (and other places) that handle the numeric types so that one doesn't have to worry about when to use toInt and when to use scanf (like for floats) or some other mechanism. Similarly the std.date.parse function could be renamed fromString. Other module might also have fromStrings. For std.conv I'm thinking
>> template fromString(T : int) {
> T fromString(char[] str) {
> return toInt(str);
> }
> }
> template fromString(T : uint) {
> T fromString(char[] str) {
> return toUint(str);
> }
> }
> ... etc...
>> The date module could use a function instead of a template since there would be only 1 fromString in the module and so there's no need to use templates to specify the return type.
>> thoughts?
> -Ben
>>