December 10, 2006
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
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
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
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
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
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
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
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
"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
"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.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Top | Discussion index | About this forum | D home