In article <c9qiqn$1i01$1@digitaldaemon.com>, Walter says...

>The trouble with allowing structs to have constructors, is <snip>
>
>If everyone would be satisfied with 1) no destructors and 2) bit copies for assignment and copy constructor and 3) no RAII for structs, I would be much more amenable to adding them in <g>.

So, two months have gone by since the above quote, and pretty much everyone has said they could live with 1), 2) and 3). And now we have constructors for primitives. You see where this is leading...?


The thing that we really need for generic programming, though, is consistency. As near as possible - the same syntax for all types. Consider the follwing possible D statements:

(1)    T x = new T();
(2)    T* x = new T();
(3)    T x = T();

(1) is appropriate for classes only; (2) is appropriate for primitives allocated
on the heap only; (3) is appropriate for either structs or classes which happen
to have overridden static opCall(). This is very counterintuitive. So, how hard
would it be to make something like:

#    T x();

construct all types, as it does in C++? (Oh, and to have

#    int x(5);

initialize x to 5, not 0, as it does in C++)? I'm not too bothered about the exact syntax (althernatives have been suggested by others), only that the syntax be the same for everything. Oh, and primitives and structs should still end up on the stack, not the heap - it's not /allocating/ them that's desirable, it's /initializing/ them (with consistent syntax).

Arcane Jill

>If everyone would be satisfied with 1) no destructors and 2) bit copies for assignment and copy constructor and 3) no RAII for structs, I would be much more amenable to adding them in <g>.

I have no problim with not having destructors in structs.
I'm not sure if I like 2). Why is it important?
Imagine you have some caches for lazy evaluation or what ever. But hey, when we
get C'tors for not having user defined assignment operatos (which we currently
don't have too) I can live with that.


And doesn't 1) imply 3)?

> I'm not just nitpicking because I don't like "new".

Yes. new just doesn't make sense. It's more to type and it doesn't give any
usefull information.
In C++ you need new.
.. = new Foo() // constructed on the heap
.. =  Foo() // constructed on the stack


There are many languages, where you can construct things without new and everybody is happy with it. Why is "new" there in D? I never understood it. I didn't in Java, eigther.


-- Matthias Becker

>Using opCall for non-new applications is only confusing if you typically overload the opCall to mean "new".  The normal use of opCall (in my opinion) is as a "functor", i.e. "operator()" in C++.  Suppose I have a function:
>
>flip(int a)
>{
>..
>}
>
>..and code that calls it.  I can make it into an object, which is then used as a function, but also holds state and may have other methods.
>
>This ability to tack state, ie member vars, onto a function by converting into a class and using it as a functor is useful to a lot of folks.  The C++ STL for example is designed to allow functors in almost all places where a function would otherwise be used.  Your opCall syntax conflicts with that idiom.
>

So your problem is that we break with a C++ idiom in D? Even if this were true, it would be stupid. But you forgot the small keyword "static". So the C++ idiom doesn't conflict with our "idiom" that you can find in a lot more languages than just one.

Remember: We want: "Foo()" instead of "new Foo()". In C++ you already have this
if you constuct on the stack!


-- Matthias Becker

In article <cf7liq$i01$1@digitaldaemon.com>, Matthias Becker says...

>>If everyone would be satisfied with 1) no destructors and 2) bit copies for assignment and copy constructor and 3) no RAII for structs, I would be much more amenable to adding them in <g>.

>I have no problim with not having destructors in structs. I'm not sure if I like 2).

Which would you prefer?
(a) no constructors for structs, at all, ever.
(b) constructors for structs, but no bitwise copying.

Remember - there is no (c). There is no third alternative - not according to
Walter's quote above. You may think you're arguing for (c), but you're not.
Walter's quote implies that only (a) and (b) are on offer. Nothing else. No
other choice. If you reject (b), the only choice left is (a). And I suspect you
didn't want inadvertantly to vote for that.



>Why is it important?

Squillions of reasons: temporary results; returning values from functions; the list is endless. Also, recall that in C++, operator=() is effectively equivalent to a destructor call followed by a constructor call (and in some cases is actually implemented that way). But if we're ruling out destructors, what would opAssign() do that a constructor didn't?



>And doesn't 1) imply 3)?

Yes. But (3) doesn't imply (1). Maybe Walter was expecting some folk to say "we
want destructors but not RAII" or something. That didn't happen.

Jill