www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.conv

reply imr1984 <imr1984_member pathlink.com> writes:
Why does std.conv not contain methods for string to floating point conversions?

Where in Phobos is this functionality?
Apr 13 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message 
news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point 
 conversions?

 Where in Phobos is this functionality?


std.string has all the toString() functions.  But I agree with you, the 
toString functions would make more sense to be in std.conv.
Apr 13 2005
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:d3jrfp$2a78$1 digitaldaemon.com...

 "imr1984" <imr1984_member pathlink.com> wrote in message 
 news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point 
 conversions?

 Where in Phobos is this functionality?


 std.string has all the toString() functions.  But I agree with you, the 
 toString functions would make more sense to be in std.conv.


Oh, I'm an idiot.  I thought you wrote floating point to string conversions. 
A D-compatible atof() is also found in std.string.  It's in the form real 
atof(char[] s).
Apr 13 2005
prev sibling parent "Kris" <fu bar.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote

 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point
 conversions?

 Where in Phobos is this functionality?


 std.string has all the toString() functions.  But I agree with you, the
 toString functions would make more sense to be in std.conv.


I agree. Mango, for example, has a dedicated package called mango.format,
which handles the formatting and parsing of various types, including
floating-point (as a bonus it includes David Gay's code as an option, which
provides extensive and thorough coverage of conversion between text and
floating-point representations).
Apr 13 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message 
news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point 
 conversions?

 Where in Phobos is this functionality?


std.math2 has atof. Strangly enough this was the topic of a recent post by 
David L Davis for ConvExt.d. Scroll back a few days to see his thread.
Apr 13 2005
next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <d3jrl5$2ab2$1 digitaldaemon.com>, Ben Hinkle says...

"imr1984" <imr1984_member pathlink.com> wrote in message 
news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point 
 conversions?

 Where in Phobos is this functionality?


std.math2 has atof. Strangly enough this was the topic of a recent post by 
David L Davis for ConvExt.d. Scroll back a few days to see his thread. 


Currently I'm applying changes to the code to make it more compatible with the
std.conv code as you suggested in the "convext.d thread." And adding in the
overflow checking, if possible, cause the floating-point datatypes are very hard
to do compare against one another.

A funny side note: 
--------------------
The reason I when for using both the std.math2 functions atof() and feq(),
instead the using std.string.atof() and std.math.mfeq() functions. Was the fact
that when I wrote the code in early November 2004 with dmd v0.105,
std.string.atof() only handled float and double but not the real datatype. With
std.math.mfeq() I wanted to use it for comparing floating-points, but it was
defined as a private function...in which I asked Walter nicely if he would make
it public function, in which he said it wasn't good enough for general use. So
at this point when I found std.math2 and the two needed functions, otherwise I
think I would've stopped my work on the project.

Also today I started looking at the std.string.atof() function again and noticed
to my surprise that it now handles real datatype..."HEY! When did that happen?" 

The following is what I discovered:

----------------------------------------
std.string in dmd from v0.105 and v0.106
----------------------------------------
extern (C)
{
// Functions from the C library.
double atof(char *);
}

---------------------------------------
std.string in dmd from v0.107 to v0.119
---------------------------------------
real atof(char[] s)
{
// BUG: should implement atold()
return std.c.stdlib.atof(toStringz(s));
}

--------------------------
std.string in dmd v0.120.2
--------------------------
extern (C)
{
// Functions from the C library.
real strtold(char*, char**);
}

/*************************************
* Convert string to float
*/
real atof(char[] s)
{   char* endptr;
real result;

result = strtold(toStringz(s), &endptr);
return result;
}

So it's now clear to me, that Walter has been busy in the area! I can't wait to
have a complete std.conv that mirrors the toString() functions for converting
from a string (char[]) back into the floating-point datatypes. 

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Apr 13 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"David L. Davis" <SpottedTiger yahoo.com> wrote in message 
news:d3k94m$2lr5$1 digitaldaemon.com...

 In article <d3jrl5$2ab2$1 digitaldaemon.com>, Ben Hinkle says...

"imr1984" <imr1984_member pathlink.com> wrote in message
news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point
 conversions?

 Where in Phobos is this functionality?


std.math2 has atof. Strangly enough this was the topic of a recent post by
David L Davis for ConvExt.d. Scroll back a few days to see his thread.


 Currently I'm applying changes to the code to make it more compatible with 
 the
 std.conv code as you suggested in the "convext.d thread." And adding in 
 the
 overflow checking, if possible, cause the floating-point datatypes are 
 very hard
 to do compare against one another.


Hmm. I haven't thought about it too much but I thought the overflow checking 
was for handling strings with a number with, say, a huge exponent that 
floating pt numbers couldn't represent and instead puts in real.max or 
whatever. Which floats are being compared? I don't know the algorithm used 
by toInt and friends or by toFloat.


 A funny side note:
 --------------------
 The reason I when for using both the std.math2 functions atof() and feq(),
 instead the using std.string.atof() and std.math.mfeq() functions. Was the 
 fact
 that when I wrote the code in early November 2004 with dmd v0.105,
 std.string.atof() only handled float and double but not the real datatype. 
 With
 std.math.mfeq() I wanted to use it for comparing floating-points, but it 
 was
 defined as a private function...in which I asked Walter nicely if he would 
 make
 it public function, in which he said it wasn't good enough for general 
 use. So
 at this point when I found std.math2 and the two needed functions, 
 otherwise I
 think I would've stopped my work on the project.

 Also today I started looking at the std.string.atof() function again and 
 noticed
 to my surprise that it now handles real datatype..."HEY! When did that 
 happen?"

 The following is what I discovered:

 ----------------------------------------
 std.string in dmd from v0.105 and v0.106
 ----------------------------------------
 extern (C)
 {
 // Functions from the C library.
 double atof(char *);
 }

 ---------------------------------------
 std.string in dmd from v0.107 to v0.119
 ---------------------------------------
 real atof(char[] s)
 {
 // BUG: should implement atold()
 return std.c.stdlib.atof(toStringz(s));
 }

 --------------------------
 std.string in dmd v0.120.2
 --------------------------
 extern (C)
 {
 // Functions from the C library.
 real strtold(char*, char**);
 }

 /*************************************
 * Convert string to float
 */
 real atof(char[] s)
 {   char* endptr;
 real result;

 result = strtold(toStringz(s), &endptr);
 return result;
 }

 So it's now clear to me, that Walter has been busy in the area! I can't 
 wait to
 have a complete std.conv that mirrors the toString() functions for 
 converting
 from a string (char[]) back into the floating-point datatypes.


interesting... and here std.math2 has probably been sitting idle all that 
time, too. How does std.string.atof compare to std.math2.atof? Have you 
compared them?
Apr 13 2005
parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d3kieb$2rog$1 digitaldaemon.com>, Ben Hinkle says...

Hmm. I haven't thought about it too much but I thought the overflow checking 
was for handling strings with a number with, say, a huge exponent that 
floating pt numbers couldn't represent and instead puts in real.max or 
whatever. Which floats are being compared? I don't know the algorithm used 
by toInt and friends or by toFloat.


Because the std.math2.atof( char[] s ) and std.string.atof( char[] s ) functions
both return a real value, it becomes important to test for an overflow for
float, ifloat, cfloat, double, idouble, and cdouble datatypes, because the
converted floating-point could be in the real datatype's range, but not
theirs...thus it should be an error.


interesting... and here std.math2 has probably been sitting idle all that 
time, too. How does std.string.atof compare to std.math2.atof? Have you 
compared them? 


Using the example code below focusing mainly on the real datatype, it would
appear, when using the %a that the std.math2.atof() (written totally in D by the
way) is a bit better than the new improved std.string.atof() (which calls a C
function to do the work). But otherwise they do get the same result in
std.string.toString( real ) and when being printed out with a %g in writefln()
function. I'll have to test the others over the next few days to see if
everything still matches up. :)









































Output:
-------
C:\dmd>dmd floattest.d
C:\dmd\bin\..\..\dm\bin\link.exe floattest,,,user32+kernel32/noi;

C:\dmd>floattest.d

C:\dmd>floattest
real.min=3.3621e-4932, real.max=1.18973e+4932

toString("3.3621e-4932")="3.3621e-4932",
toString("1.18973e+4932")="1.18973e+4932"

toString(real.min)="3.3621e-4932", 
toString(real.max)="1.18973e+4932"

std.string.atof() r1.min=0x1.ffffe0a1926d0c4cp-16384,
r2.max=0x1.ffffd5d36dc5106p+16383
std.string.atof() r1.min=3.3621e-4932, r2.max=1.18973e+4932

std.math2.atof()  r1.min=0x1.ffffe0a1926cf074p-16384,
r2.max=0x1.ffffd5d36dc52c4p+16383
std.math2.atof()  r1.min=3.3621e-4932, r2.max=1.18973e+4932

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Apr 13 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Again, this is a point for implicit imports.  If a person knows what they need
to do, and can find a common function that can do it, then it shouldn't matter
whether or not they know what module the function is in.  They should simply be
able to use it.

The only times a module should "need" to be explicitly implied is if it's not
in the implicit import list, or if the version that's wanted is in a module
other than the one that the implicit import list specifies.  In fact, it would
even be possible for implicit importing to be "version" sensative, and not
implicitly import a module if the list dpecifies that the called function,
object, or whatever, doesn't work in the version specified in the last
"version()" statement.

TZ

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d3jrl5$2ab2$1 digitaldaemon.com...

 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:d3jq4r$28g6$1 digitaldaemon.com...

 Why does std.conv not contain methods for string to floating point
 conversions?

 Where in Phobos is this functionality?


 std.math2 has atof. Strangly enough this was the topic of a recent post by
 David L Davis for ConvExt.d. Scroll back a few days to see his thread.
Apr 14 2005
parent reply J C Calvarese <jcc7 cox.net> writes:
TechnoZeus wrote:

 Again, this is a point for implicit imports.  If a person knows what they need
to do, and can find a common function that can do it, then it shouldn't matter
whether or not they know what module the function is in.  They should simply be
able to use it.
 
 The only times a module should "need" to be explicitly implied is if it's not
in the implicit import list, or if the version that's wanted is in a module
other than the one that the implicit import list specifies.  In fact, it would
even be possible for implicit importing to be "version" sensative, and not
implicitly import a module if the list dpecifies that the called function,
object, or whatever, doesn't work in the version specified in the last
"version()" statement.
 
 TZ


There is absolutely no way that Walter is going to add implicit imports 
(other than object.d) to D. Here's how I know: many people have asked to 
allow "import pkg.*" to import all of a directory and he's shown no sign 
of budging on even that. What you seem to be asking for a hidden "import 
*" at the beginning of every program. The reason why he hasn't 
implemented "import pkg.*" isn't because it's hard to implement (I'm 
fairly certain it'd be quite easy to implement). He hasn't implemented 
it because he thinks it'd lead to more pesky, weird, and unpredictable 
bugs in D programs. (FWIW, I think he's right.)

If you really want to have "implicit imports", I think that you can get 
pretty close using some of D's current functionality (assuming you 
actually are interesting in using D).

You can create a file (let's call it "all.d") with this content:

public import
std.array,
std.asserterror,
std.base64,
std.compiler,
std.conv,
std.ctype,
std.date,
std.dateparse,
std.file,
std.format,
std.gc
/* etc. */
;

(If this sounds like a lot of typing it'd be pretty easy to write a 
program to search through the file system automatically creating "all.d".)

Then at the beginning of every program you write, you would simply add 
"import all.d". One line of code at the top of your program shouldn't be 
too high of a price to achieve nearly implicit importation.

Nonetheless, there's nothing I can do to prevent you from continuing to 
ask for implicit importing. If you want it, you want it. I'm just not 
sure what you find appealing about D, since this kind of legerdemain 
seems antithetical to the D way of thinking. I'm not telling you you're 
wrong to want to program this way (how you want to program is your 
decision), but I'm thinking there might be a programming language that 
is closer to your goals than D is.

-- 
jcc7
http://jcc_7.tripod.com/d/
Apr 16 2005
next sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Again, this misses my point.  You're talking about importing a bunch of stuff
whether it's needed or not.  I'm talking about importing something when it's
needed, and what ever else is impossible to separate from it at that time.

TZ

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d3sp25$vns$1 digitaldaemon.com...

 TechnoZeus wrote:

 Again, this is a point for implicit imports.  If a person knows what they need
to do, and can find a common function that can do it, then it shouldn't matter
whether or not they know what module the function is in.  They should simply be
able to use it.

 The only times a module should "need" to be explicitly implied is if it's not
in the implicit import list, or if the version that's wanted is in a module
other than the one that the implicit import list specifies.  In fact, it would
even be possible for implicit importing to be "version" sensative, and not
implicitly import a module if the list dpecifies that the called function,
object, or whatever, doesn't work in the version specified in the last
"version()" statement.

 TZ


 There is absolutely no way that Walter is going to add implicit imports
 (other than object.d) to D. Here's how I know: many people have asked to
 allow "import pkg.*" to import all of a directory and he's shown no sign
 of budging on even that. What you seem to be asking for a hidden "import
 *" at the beginning of every program. The reason why he hasn't
 implemented "import pkg.*" isn't because it's hard to implement (I'm
 fairly certain it'd be quite easy to implement). He hasn't implemented
 it because he thinks it'd lead to more pesky, weird, and unpredictable
 bugs in D programs. (FWIW, I think he's right.)

 If you really want to have "implicit imports", I think that you can get
 pretty close using some of D's current functionality (assuming you
 actually are interesting in using D).

 You can create a file (let's call it "all.d") with this content:

 public import
 std.array,
 std.asserterror,
 std.base64,
 std.compiler,
 std.conv,
 std.ctype,
 std.date,
 std.dateparse,
 std.file,
 std.format,
 std.gc
 /* etc. */
 ;

 (If this sounds like a lot of typing it'd be pretty easy to write a
 program to search through the file system automatically creating "all.d".)

 Then at the beginning of every program you write, you would simply add
 "import all.d". One line of code at the top of your program shouldn't be
 too high of a price to achieve nearly implicit importation.

 Nonetheless, there's nothing I can do to prevent you from continuing to
 ask for implicit importing. If you want it, you want it. I'm just not
 sure what you find appealing about D, since this kind of legerdemain
 seems antithetical to the D way of thinking. I'm not telling you you're
 wrong to want to program this way (how you want to program is your
 decision), but I'm thinking there might be a programming language that
 is closer to your goals than D is.

 -- 
 jcc7
 http://jcc_7.tripod.com/d/
Apr 19 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <d43cvo$13bd$1 digitaldaemon.com>, TechnoZeus says...

Again, this misses my point.  


I understand your point. Perhaps you don't understand mine. I don't expect you
to agree with me anyways, so I'll leave it at that.


You're talking about importing a bunch of stuff whether it's needed or not. 
>I'm talking about importing something when it's needed, and what ever else is 
impossible to separate from it at that time.

TZ

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d3sp25$vns$1 digitaldaemon.com...

 TechnoZeus wrote:

 Again, this is a point for implicit imports.  If a person knows what they need
to do, and can find a common function that can do it, then it shouldn't matter
whether or not they know what module the function is in.  They should simply be
able to use it.

 The only times a module should "need" to be explicitly implied is if it's not
in the implicit import list, or if the version that's wanted is in a module
other than the one that the implicit import list specifies.  In fact, it would
even be possible for implicit importing to be "version" sensative, and not
implicitly import a module if the list dpecifies that the called function,
object, or whatever, doesn't work in the version specified in the last
"version()" statement.

 TZ


 There is absolutely no way that Walter is going to add implicit imports
 (other than object.d) to D. Here's how I know: many people have asked to
 allow "import pkg.*" to import all of a directory and he's shown no sign
 of budging on even that. What you seem to be asking for a hidden "import
 *" at the beginning of every program. The reason why he hasn't
 implemented "import pkg.*" isn't because it's hard to implement (I'm
 fairly certain it'd be quite easy to implement). He hasn't implemented
 it because he thinks it'd lead to more pesky, weird, and unpredictable
 bugs in D programs. (FWIW, I think he's right.)

 If you really want to have "implicit imports", I think that you can get
 pretty close using some of D's current functionality (assuming you
 actually are interesting in using D).

 You can create a file (let's call it "all.d") with this content:

 public import
 std.array,
 std.asserterror,
 std.base64,
 std.compiler,
 std.conv,
 std.ctype,
 std.date,
 std.dateparse,
 std.file,
 std.format,
 std.gc
 /* etc. */
 ;

 (If this sounds like a lot of typing it'd be pretty easy to write a
 program to search through the file system automatically creating "all.d".)

 Then at the beginning of every program you write, you would simply add
 "import all.d". One line of code at the top of your program shouldn't be
 too high of a price to achieve nearly implicit importation.

 Nonetheless, there's nothing I can do to prevent you from continuing to
 ask for implicit importing. If you want it, you want it. I'm just not
 sure what you find appealing about D, since this kind of legerdemain
 seems antithetical to the D way of thinking. I'm not telling you you're
 wrong to want to program this way (how you want to program is your
 decision), but I'm thinking there might be a programming language that
 is closer to your goals than D is.

 -- 
 jcc7
 http://jcc_7.tripod.com/d/




jcc7
Apr 19 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
You're right... I looked over what you had said, and there is a point in it
that I had missed.  Your comparison isn't valid though, because implicit
imports would be standardized in the same way as built-in parts of the language
are... so there would be no unpredictability.

I'm not talking about importing a bunch of stuff that the programmer doesn't
want.  I'm talking about importing standard things that the programmer chooses
to use without forcing the programmer to first explicitly tell the compiler
where to find them.  The choice to specify an alternative location would still
exist, and the choice to explicitly specify the "usual" location would also
still exist, but the programmer would be free to let the compiler find the
usual things in the usual places automatically if they are used without an
explicit import.

Of course, it wouldn't be difficult to make a compiler switch that could turn
all implicit importing off, or one that would leave it on but report each
instance of it, I would think.  That would be enough to satisfy those who are
worried about possibly telling their program to use something that just happens
to match a name in the implicit import list but was actually a custom componant
that they forgot to include... but even without the compiler set to skip or
report implicit imports, they would most likely find that their code wouldn't
compile because the implicitly imported item would likely fail to accept the
same parameters as their intended custom item.

More to the point, it would be entirely predictable.... but would make D easier
to learn and use in a shorter time.  It would also get rid of a huge bug in C
and C++ that D has so far inhereted in force... and that is the documentation
bug which frequently shows up when someone is so used to something that has
become "standard" that they forget it's not "built in" and write about it as if
it's a part of the language, when it's not.  Implicit importation of "standard"
items would make them effectively part of the language, but without causing
code bloat.

TZ

TZ

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d43g10$16dh$1 digitaldaemon.com...

 In article <d43cvo$13bd$1 digitaldaemon.com>, TechnoZeus says...

Again, this misses my point.


 I understand your point. Perhaps you don't understand mine. I don't expect you
 to agree with me anyways, so I'll leave it at that.


You're talking about importing a bunch of stuff whether it's needed or not. 
>I'm talking about importing something when it's needed, and what ever else is 
impossible to separate from it at that time.

TZ

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d3sp25$vns$1 digitaldaemon.com...

 TechnoZeus wrote:

 Again, this is a point for implicit imports.  If a person knows what they need
to do, and can find a common function that can do it, then it shouldn't matter
whether or not they know what module the function is in.  They should simply be
able to use it.

 The only times a module should "need" to be explicitly implied is if it's not
in the implicit import list, or if the version that's wanted is in a module
other than the one that the implicit import list specifies.  In fact, it would
even be possible for implicit importing to be "version" sensative, and not
implicitly import a module if the list dpecifies that the called function,
object, or whatever, doesn't work in the version specified in the last
"version()" statement.

 TZ


 There is absolutely no way that Walter is going to add implicit imports
 (other than object.d) to D. Here's how I know: many people have asked to
 allow "import pkg.*" to import all of a directory and he's shown no sign
 of budging on even that. What you seem to be asking for a hidden "import
 *" at the beginning of every program. The reason why he hasn't
 implemented "import pkg.*" isn't because it's hard to implement (I'm
 fairly certain it'd be quite easy to implement). He hasn't implemented
 it because he thinks it'd lead to more pesky, weird, and unpredictable
 bugs in D programs. (FWIW, I think he's right.)

 If you really want to have "implicit imports", I think that you can get
 pretty close using some of D's current functionality (assuming you
 actually are interesting in using D).

 You can create a file (let's call it "all.d") with this content:

 public import
 std.array,
 std.asserterror,
 std.base64,
 std.compiler,
 std.conv,
 std.ctype,
 std.date,
 std.dateparse,
 std.file,
 std.format,
 std.gc
 /* etc. */
 ;

 (If this sounds like a lot of typing it'd be pretty easy to write a
 program to search through the file system automatically creating "all.d".)

 Then at the beginning of every program you write, you would simply add
 "import all.d". One line of code at the top of your program shouldn't be
 too high of a price to achieve nearly implicit importation.

 Nonetheless, there's nothing I can do to prevent you from continuing to
 ask for implicit importing. If you want it, you want it. I'm just not
 sure what you find appealing about D, since this kind of legerdemain
 seems antithetical to the D way of thinking. I'm not telling you you're
 wrong to want to program this way (how you want to program is your
 decision), but I'm thinking there might be a programming language that
 is closer to your goals than D is.

 -- 
 jcc7
 http://jcc_7.tripod.com/d/




 jcc7
Apr 20 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:

 Again, this misses my point.  You're talking about importing a bunch
 of stuff whether it's needed or not.  I'm talking about importing
 something when it's needed, and what ever else is impossible to
 separate from it at that time.
 
 TZ


The origins may be very different, but the end result may be the same.
(IIRC,) in your final binary, only the things that _actually_ get used,
are incorporated. (Please anyone, correct me if I'm wrong here.)


 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:d3sp25$vns$1 digitaldaemon.com...
 

 TechnoZeus wrote:
 

 Again, this is a point for implicit imports.  If a person knows
 what they need to do, and can find a common function that can do
 it, then it shouldn't matter whether or not they know what module
 the function is in.  They should simply be able to use it.
 
 The only times a module should "need" to be explicitly implied is
 if it's not in the implicit import list, or if the version that's
 wanted is in a module other than the one that the implicit import
 list specifies.  In fact, it would even be possible for implicit
 importing to be "version" sensative, and not implicitly import a
 module if the list dpecifies that the called function, object, or
 whatever, doesn't work in the version specified in the last
 "version()" statement.
 
 TZ


 
 There is absolutely no way that Walter is going to add implicit
 imports (other than object.d) to D. Here's how I know: many people
 have asked to allow "import pkg.*" to import all of a directory and
 he's shown no sign of budging on even that. What you seem to be
 asking for a hidden "import *" at the beginning of every program.
 The reason why he hasn't implemented "import pkg.*" isn't because
 it's hard to implement (I'm fairly certain it'd be quite easy to
 implement). He hasn't implemented it because he thinks it'd lead to
 more pesky, weird, and unpredictable bugs in D programs. (FWIW, I
 think he's right.)
 
 If you really want to have "implicit imports", I think that you can
 get pretty close using some of D's current functionality (assuming
 you actually are interesting in using D).
 
 You can create a file (let's call it "all.d") with this content:
 
 public import std.array, std.asserterror, std.base64, std.compiler,
  std.conv, std.ctype, std.date, std.dateparse, std.file, 
 std.format, std.gc /* etc. */ ;
 
 (If this sounds like a lot of typing it'd be pretty easy to write a
  program to search through the file system automatically creating
 "all.d".)
 
 Then at the beginning of every program you write, you would simply
 add "import all.d". One line of code at the top of your program
 shouldn't be too high of a price to achieve nearly implicit
 importation.
 
 Nonetheless, there's nothing I can do to prevent you from
 continuing to ask for implicit importing. If you want it, you want
 it. I'm just not sure what you find appealing about D, since this
 kind of legerdemain seems antithetical to the D way of thinking.
 I'm not telling you you're wrong to want to program this way (how
 you want to program is your decision), but I'm thinking there might
 be a programming language that is closer to your goals than D is.
 
 -- jcc7 http://jcc_7.tripod.com/d/
Apr 19 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
J C Calvarese wrote:

 TechnoZeus wrote:
 

 Again, this is a point for implicit imports.  If a person knows what 
 they need to do, and can find a common function that can do it, then 
 it shouldn't matter whether or not they know what module the function 
 is in.  They should simply be able to use it.

 The only times a module should "need" to be explicitly implied is if 
 it's not in the implicit import list, or if the version that's wanted 
 is in a module other than the one that the implicit import list 
 specifies.  In fact, it would even be possible for implicit importing 
 to be "version" sensative, and not implicitly import a module if the 
 list dpecifies that the called function, object, or whatever, doesn't 
 work in the version specified in the last "version()" statement.

 TZ


 
 
 There is absolutely no way that Walter is going to add implicit imports 
 (other than object.d) to D. Here's how I know: many people have asked to 
 allow "import pkg.*" to import all of a directory and he's shown no sign 
 of budging on even that. What you seem to be asking for a hidden "import 
 *" at the beginning of every program. The reason why he hasn't 
 implemented "import pkg.*" isn't because it's hard to implement (I'm 
 fairly certain it'd be quite easy to implement). He hasn't implemented 
 it because he thinks it'd lead to more pesky, weird, and unpredictable 
 bugs in D programs. (FWIW, I think he's right.)
 
 If you really want to have "implicit imports", I think that you can get 
 pretty close using some of D's current functionality (assuming you 
 actually are interesting in using D).
 
 You can create a file (let's call it "all.d") with this content:
 
 public import
 std.array,
 std.asserterror,
 std.base64,
 std.compiler,
 std.conv,
 std.ctype,
 std.date,
 std.dateparse,
 std.file,
 std.format,
 std.gc
 /* etc. */
 ;
 
 (If this sounds like a lot of typing it'd be pretty easy to write a 
 program to search through the file system automatically creating "all.d".)
 
 Then at the beginning of every program you write, you would simply add 
 "import all.d". One line of code at the top of your program shouldn't be 
 too high of a price to achieve nearly implicit importation.


Considering this, it might not be that Walter has any reasons of 
Principle against this -- just that this being this easy to implement, 
warrants it not being part "of the language".


 Nonetheless, there's nothing I can do to prevent you from continuing to 
 ask for implicit importing. If you want it, you want it. I'm just not 
 sure what you find appealing about D, since this kind of legerdemain 
 seems antithetical to the D way of thinking. I'm not telling you you're 
 wrong to want to program this way (how you want to program is your 
 decision), but I'm thinking there might be a programming language that 
 is closer to your goals than D is.
Apr 19 2005