"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3skqh$2hb$1@digitaldaemon.com...
> This requires multiple modules:
>
> f.d:
>     module foo.bar;
>     import g;
>
> g.d:
>     import f;
>
> Using "dmd f.d" complains that "g.d(1): module f is in multiple packages
> foo.bar".

Hmmm. Looks like a compiler bug.

> Secondly, you say that you made "private" mean "static", but that doesn't work either:
>
> f.d:
>     import g;
>
>     void main()
>     {
>        int x = foo;
>     }
>
> g.d:
>     private int foo;
>
> Using "dmd -c f.d" on this code compiles, even though it's an error.

I just fixed that one last night <g>.

Perhaps they should have chosen to make explicit behavior the default, and added an "implicit" keyword instead.  Implicit conversion is still very useful under controlled circumstances.

I find that, like operator overloading and templates, implicit construction/conversion is one of those language features that people strongly lobby against because they have personally been burned by it at some point in the past.  What they don't realize is that, with proper care, it can be a VERY powerful language feature that make solving some particular problem feasible or at least easier.  When combined with templates, implicit conversion might allow you to express something that you couldn't otherwise say because you don't know or don't have handy access to the name of the type you want it converted to, or don't care if the types match exactly.

I can't justify exclusion of a feature because you don't happen to like it and have a description of a circumstance in which you shot yourself in the foot with it.

In C++ I use implicit user-defined conversion to bool, int, and float all the time.  A colleague at work just made a "smart enum" class that uses it; this enum knows how to convert itself to and from a string automatically.

Sean

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b3t8hp$blq$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b3sc9l$2uvl$1@digitaldaemon.com...
> > You're right... and you can't mark a user-defined cast as "explicit".
I'd
> > much rather have just constructors.  Problem is, you can't add
> constructors
> > to other classes such as "int".
> >
>
> To me, a need for "explicit" is just a sign that there is something inherently wrong with the 'feature' of implicit object creation when a single-argument constructor exists. Consider a function
>
> void f( SomeClass c )
>
> That means, that c needs to be of type 'SomeClass' (or a subclass of
that).
> C++ actually allows you to have another class with a 1-argument
constructor
>
> class CompletelyDifferentClass
> {
>     CompletelyDifferentClass( SomeClass c )    // 1-argument constructor
> }
>
> and then (perhaps even depending on visiblity, I'm not sure here, and also if SomeClass is not abstract) you can do
>
> CompletelyDifferentClass d;
> f( d )
>
> Reading this code without the class or function declarations would make
you
> think that either (1) f takes a 'CompletelyDifferentClass' as an argument, or (2) a superclass thereof. Instead, _implicitly_ a new, temporary object of class SomeClass is created, using the 1-argument constructor. Horror!
No
> reference to 'SomeClass' is made in the above code fragment, yet it is involved. So this means that a 1-argument constructor models "is_a" (while in fact it is "can_be_constructed_from_a")
>
> I vote for explicit object construction always, preferrably with always
the
> same language construct ("new" will do fine).
>
> PS Following this line of thought, the C# feature of "boxing" does not appeal to me either. They claim that "everything is an object" (Marketing: "much better than Java"), but underwater some things are more object than others, heavily affecting performance as a "side effect"

Assertions don't use the file name assigned through #line.  For example:

blat.d:
   #file 64 "foobar"
   void main()
   {
      assert(0);
   }

Compiling this with "dmd blat.d" and running it reports "Error: Assertion Failure blat.d(66)".