View mode: basic / threaded / horizontal-split · Log in · Help
December 10, 2006
Re: DMD 0.177 release
Samuel MV wrote:
> Thank you, Walter.
> 
> D 1.0 is going to be THE BEST general purpose language ... :D
s/general purpose \(language\)/\1 EVER/

...or such :P
December 10, 2006
Re: DMD 0.177 release
David L. Davis wrote:
> Walter in dmd v0.176 you improved name mangling, but I've found one very 
> confusing change...is it your intension to reuse the "b" which used to mean 
> "bit," to now mean a "bool" instead of "x?"

> For example, one function "real vdb(real, real, real, real, real, real, bool 
> = false)" used in my financial D dll,
> before dmd v0.148 was released when the "bool" data type was added 
> (replacing the "bit" data type) the function's mangled name was 
> "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
> data type become an alias to bool and all the "b" (for "bit") were replaced 
> with "x" (for "bool"), thus the funtion's mangled name changed to become 
> "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
> replaced by "b," is this a mistake on your part, or have you decided to use 
> a "b" as meaning a "bool" (discarding "x")?

Between 0.148 and 0.175, function pointers used 'b' for 'bool', but the 
functions themselves used 'x'. It was a bit inconsistent.
December 10, 2006
Re: DMD 0.177 release
Walter Bright wrote:
> 2) trying to keep track of every struct created is going to put a hole 
> below the waterline in some new capabilities planned for the future. The 
> compiler needs to be able to willy-nilly create bit copies of structs 
> for this to work. C++ has this problem in spades (just follow the 
> skin-rending and hair-pulling going on with the "move constructor" 
> issues). Allowing the compiler to be able to create bit copied 
> temporaries without needing to call constructors is going to be 
> worthwhile by enabling some pretty cool stuff.

Intriguing. Evidently the ideas barrel is far from empty. <g>
December 11, 2006
Re: DMD 0.177 release
Walter Bright wrote:
> It's time to put the recurring efficiency argument to bed. Consider this 
> D code:

That is a relief to know.  What about heap construction?  I think 
currently with the opCall approach you have to do something like:
  auto x = new Struct;
  *x = Struct(args);
Does that copy get optimized away too?

There are other issues people are concerned about also.   Maybe it does 
only take two extra lines to define a static opCall vs a constructor, 
but that extra two lines is basically redundant noise and makes static 
opCall look hackish.  And given that most every struct is going to need 
a constructor, it is hackish noise that we're all going to have to (and 
already do) see a lot.

Also the name "static opCall" doesn't exactly scream out "i'm a 
constructor". And there's no guarantee that if I'm given a random struct 
I'll be able to use StructName() as a constructor.  Users are free to do 
whatever they want with static opCall.  With a constructor you have to 
construct.  Just like you said "constructors should construct objects" 
-- ok, but static opCall is not intrinsically a constructor, any more 
than a function called make() is a constructor.  It might be used as a 
constructor, or it might not.

There's also the consistency issue, that if construction is done with 
'this()' for classes it should be done with 'this()' for structs.

I can kind of see why you don't want to use this() because in classes 
that's triggered by using the 'new' keyword, and for stack construct 
structs it makes sense to not use 'new'.  But then if structs can be 
value constructed with  x = Struct(), then why not classes too?  But 
classes have to be value constructed using 'scope'.

Ok, what if you just sidestep all that and introduce something like 
opCreate for structs.  Basically this would be identical to the current 
"static opCall", but you could write the code for it just like a 
constructor.  Like so:

   opCreate(int arg) {
      m_member = arg;
   }

I.e. you don't specify return type, return value, or 'static' etc.  It 
works just like a constructor, but you call it like static opCall.

   auto x = MyStruct()

It would be an error to have both a static opCall and an opCreate.

Of course at that point it really raises the question "why not just call 
it 'this' instead of opCreate".  And declare that for structs you can 
invoke 'this' by using x = MyStruct().

Anyway, I really don't see why it has to be an either/or situation.  Let 
people use this/opCreate for new code, and let them continue to use 
static opCall in old code.  But make it an error to have both in a 
struct.  What's so hard about that?

--bb
December 11, 2006
Re: DMD 0.177 release
Bill Baxter wrote:
> There's also the consistency issue, that if construction is done with 
> 'this()' for classes it should be done with 'this()' for structs.
> 

One issue I have with allowing struct constructors is that the existence 
of struct constructors implies the existence of struct destructors. Do 
we really want to go that far? Though "static opCall" doesn't scream 
"constructor," it also doesn't seem to imply the user could define a 
destructor. I submit that "this()" would.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
December 11, 2006
Re: DMD 0.177 release
Kirk McDonald wrote:
> Bill Baxter wrote:
>> There's also the consistency issue, that if construction is done with 
>> 'this()' for classes it should be done with 'this()' for structs.
>>
> 
> One issue I have with allowing struct constructors is that the existence 
> of struct constructors implies the existence of struct destructors. Do 
> we really want to go that far? Though "static opCall" doesn't scream 
> "constructor," it also doesn't seem to imply the user could define a 
> destructor. I submit that "this()" would.

That seems like a non-issue to me.  Even if people do take that to mean 
you can have a destructor, the compiler will crush any such delusions 
the moment you try to compile a struct with ~this in it. The compiler 
error message could even be "Structs cannot have destructors, only 
classes can".  That should be pretty clear.

Structs and classes are different in D.  That's a fact, and new users 
are going to have to deal with it sooner or later.  Should the language 
emphasize the similarities or stress the differences?  I don't think it 
makes a big difference in this case.

What's more important I think is that core operations can be performed 
in a way that is clear and unambiguous.  No matter how you slice it, 
construction is a very common operation, and 'static opCall' does not 
offer a clear syntax for construction behavior, nor is it unambiguous in 
the sense that it can be used for any purpose the user desires.   The 
fact that everyone was convinced that it must be inefficient because it 
*looks* like it's going to do extra copies is just another side effect 
of it using unambiguous constructor-like syntax.

Walter went out of his way to avoid "looking hackish" with regard to 
foreach loops.  It seems very odd to just accept hackish-looking 
constructors for structs.

--bb
December 11, 2006
Re: DMD 0.177 release
Bill Baxter wrote:

edit:
> The fact that everyone was convinced that it must be inefficient because it 
> *looks* like it's going to do extra copies is just another side effect 
> of it using unambiguous constructor-like syntax.

I mean "a side effect of it *not* using unambiguous constructor-like 
syntax", of course.

--bb
December 11, 2006
Re: DMD 0.177 release
Kirk McDonald wrote:
> Bill Baxter wrote:
> 
>> There's also the consistency issue, that if construction is done with 
>> 'this()' for classes it should be done with 'this()' for structs.
>>
> 
> One issue I have with allowing struct constructors is that the existence 
> of struct constructors implies the existence of struct destructors. Do 
> we really want to go that far? Though "static opCall" doesn't scream 
> "constructor," it also doesn't seem to imply the user could define a 
> destructor. I submit that "this()" would.

Who knows, maybe D will have destructors for structs one day :o).

Andrei
December 11, 2006
Re: DMD 0.177 release
"Andrei Alexandrescu (See Website For Email)" 
<SeeWebsiteForEmail@erdani.org> wrote in message 
news:elihab$1q98$1@digitaldaemon.com...

> Who knows, maybe D will have destructors for structs one day :o).
>
> Andrei

I can see it now:

DMD 0.178
* Added destructors for structs.  Big thanks to Andrei.
December 11, 2006
Re: DMD 0.177 release
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
news:eliilm$1sk3$1@digitaldaemon.com...

>
> I can see it now:
>
> DMD 0.178
> * Added destructors for structs.  Big thanks to Andrei.
>

You can't see it, but there's a ";)" at the end of that post.
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home