>
> My suggestion is not to provide opAssign for classes. It is providing opAssign for structs.
>
> /Oskar

Exactly!
Classes and structures are conceptually different despite
of the fact that they share common notation.

I would suggest also to disable following:

struct mystruct {
   int myfield;
}

mystruct *pms = new mystruct;
mystruct ms;

pms.myfield = 1; // this must be an ERROR!
(*pms).myfield = 1; // this is OK
ms.myfield = 1; // this is OK

"Dave" <Dave_member@pathlink.com> wrote in message news:duci1c$22ao$1@digitaldaemon.com...
> I'm not sure what you mean by 'auto class members', but if you meant
> 'classes
> instantiated on the stack for which the dtor is automatically called when
> they
> go out of scope', then I agree.

I think he means "class reference members whose lifetime is determined by the lifetime of the object that refers to them.  i.e.

class A
{
    auto B b;

    this()
    {
        b = new B();
    }

    ~this()
    {
        writefln("A dtor");
    }
}

class B
{
    ~this()
    {
        writefln("B dtor");
    }
}

void main()
{
    {
        auto A a = new A()
    }
    writefln("Done");
}

Would print

A dtor
B dtor
Done

(Or maybe the order of the dtors would be different, but the point is that the instance of B's lifetime is dependent upon the instance of A's.)

In article <duckkp$25nc$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>>>
>>> D will GPF on something like this I guess.
>>
>> In my book, this is a Feature of D.
>
>Are you saying in your book that:
>"D will GPF" is a Feature of D?
>
>It is not for book then - it is something to be graffited on the wall I guess.

In your example, s0 is in a stack frame.  This stack frame is gone when test() exits.  If you want to fix this, you have to allocate stack frames on the heap.

Allocation of stack frames on the heap incurs a massive performance hit.  This feature isn't beneficial enough to offset that performance hit.

An alternative would be to allocate stack frames on the heap only if this behavior is used.  This would probably make things very complex when returning from / jumping to such functions, which implies another (maybe smaller, maybe not) performance hit.

Languages like javascript, ruby, take the low performance route.  In D you can accomplish an equivalent thing by putting the field in question in a class and calling new.  Then the performance hit is only for this one instance.

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:dubrg5$111g$1@digitaldaemon.com...
> I think it boils down to this - in C++ the lifetime of objects can be influenced by other objects, and as part of algorithms.  And algorithms and code can be influenced by the lifetime of objects.  In D the lifetime of objects is influenced by code, but not the other way around.
>
> Maybe this is just the cost of GC.  It seems like both methods could
> coexist,
> but if enough features are added to D it will weigh as much as C++.  I'll
> have
> to think about whether there are other cases that auto/on_scope can't do.

I've thought many times that a great deal of the complexity of C++ comes from overloaded assignment, copy ctors, etc. Every class you build essentially has to overload these. It winds up adding lots of bloat and obfuscation to every class. There's a reason why Java classes always look so simple, and C++ ones you have to wade through a lot of stuff just to figure out what the point of the class is.

> I guess what I'm saying is that in C++ you have incremental power over the
> functionality.  If you want a virtual table but no operators, you can have
> it.
> Operators but no virtual table, okay.  Each feature is turned on
> seperately.  In
> D there is struct, which has some stuff, and class, which has everything
> and a
> very different personality.

Right. And the argument with C++ is that the incrementalism gives the max efficiency possible with each situation. That argument is theoretically correct, but in practice, I find it rarely works out that way.

> This is starting to sound like a complaint, but actually I like D's way.
> All
> that syntax is why C++ is so treacherous for anyone who doesn't have a law
> degree in it.  The first ten times you write operator=(), you need to look
> at
> the book.

Yes.

> But C++'s a-la carte is powerful, if you want to spend time crafting
> the classes.  It's a tradeoff.  D makes a lot of common sense tradeoffs.
> In C++
> you can build uncopyable classes, inherit from classes that have no code
> (i.e.
> traits programming) etc.  D tosses a lot of semi-obscure flexibility and
> lets
> some of it in through other doors.  Again, good decision, but there are
> small
> ramifications here and there.
>
> I'll just force myself to stop typing now. ;)

You're right, and that was a deliberate D design decision. And I'll add to that my opinion that all those "small ramifications" do not add up to much of anything in real programs. An illustration of that is DMDScript in C++ vs D. The D one is faster, even though the C++ was carefully tuned with all those small ramifications. They didn't amount to squat in the end because the C++ version turned out to be brittle as a result (i.e. resistant to change). The D version was much easier to modify to try out different approaches, which resulted in it being faster.

"Johan Granberg" <lijat.meREM@OVEgmail.com> wrote in message news:dubpge$u3r$1@digitaldaemon.com...
>>> 1. const parameters and member functions
>>> Countless times this saved me. I just can't imagine references being
>>> passed in and out of functions without something explicitly saying that
>>> the function is expected or not to modify it.
> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.

Because the const thing has been endlessly thrashed about in other threads.

> I will not repeat all the arguments but to me this is important issues.
> If i should rank the most showstoping things in D (from my perspective) it
> would be
> 1. bugs
> 2. as far as I know no way of inporting somthing in a parent directory (as
> C++ #include "../myheader.hpp")

The -I compiler switch can specify the "root" from whence all the packages derive.

> 3. read only sematics that work as a strong reminder that one is not
> suposed to modify somthing (but can bee subverted by a cast)
> 4. overlodable assignment and copy constructors.
> 5. library and other minor issues
>
>>> 4. library
>>> ...
>> I don't find the STL compelling, either, and that's the only library thing standard C++ has over libc. Furthermore, large chunks of STL are simply irrelevant in D because D has core arrays, strings, and associative arrays.
>
> I agree on this one. So wath is your plan for the D standard library?

Keep incrementally improving it. Is there anything in particular you feel is missing?

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:duc1g3$1936$1@digitaldaemon.com...
> But this question is a bit biased and misframed.

Of course, but that is the point of it. I wanted to hear what the biases and misframes are, so they can be dealt with. I want to know the source of the perception that "C++ is more powerful."

> Java is an extreme example of this, where plainness and "shepherdness" are
> taken to an extreme, and I hear people complain about it all the time (me
> inclusive), but I also recognize that there are some advantages to this
> plainness.
> _I know_, when reading Java code, that the code isn't doing some weird,
> obscure, or just unclear thing, because Java is that plain. And that is
> something I didn't immediately realize after learning/working with Java,
> but only recently came to value and understand (and I think it might very
> well be one of the things that were responsible for Java's popularity).

Right. I discovered this too. For the lack of an existing term, I called this "inspectability", which is defined as being able to tell what code is doing *without* needing to examine declarations or header files. For example, what are the various things that f(x) can mean in C++? (There are quite a few!) Code is not inspectable in C++. Any piece of code in C++, you have essentially no reliable touchstone as to what it is doing without examining all the header files.

(This is also one big reason why D does not have user definable tokens or syntax, it makes code completely uninspectable.)

> Now, I'm not saying (nor I think) that D should be like Java in that regard, but I think it's something we should keep in mind when trying to shove every feature of other language, especially C++, into D.

You're quite right, and inspectability has been a big consideration. It's another reason why I dislike overloading assignment (as you mention).

In article <dubpge$u3r$1@digitaldaemon.com>, Johan Granberg says...
>
>>> 1. const parameters and member functions
>>>
>>> Countless times this saved me. I just can't imagine references being passed in and out of functions without something explicitly saying that the function is expected or not to modify it.
>You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.
>

A method can explicitly say that it will modify a reference by using "out" and "inout".

I've never cared much for const member methods, so I'm confused as to how a lack of them can cause such a problem. Can you give an example?

In article <ducnmj$rv$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Johan Granberg" <lijat.meREM@OVEgmail.com> wrote in message news:dubpge$u3r$1@digitaldaemon.com...
>>>> 1. const parameters and member functions
>>>> Countless times this saved me. I just can't imagine references being
>>>> passed in and out of functions without something explicitly saying that
>>>> the function is expected or not to modify it.
>> You did not answer the above statement and i have seen this repeated all over this thread along with destructors in structs.
>
>Because the const thing has been endlessly thrashed about in other threads.
>
>> I will not repeat all the arguments but to me this is important issues.
>> If i should rank the most showstoping things in D (from my perspective) it
>> would be
>> 1. bugs
>> 2. as far as I know no way of inporting somthing in a parent directory (as
>> C++ #include "../myheader.hpp")
>
>The -I compiler switch can specify the "root" from whence all the packages derive.
>
>> 3. read only sematics that work as a strong reminder that one is not
>> suposed to modify somthing (but can bee subverted by a cast)
>> 4. overlodable assignment and copy constructors.
>> 5. library and other minor issues
>>
>>>> 4. library
>>>> ...
>>> I don't find the STL compelling, either, and that's the only library thing standard C++ has over libc. Furthermore, large chunks of STL are simply irrelevant in D because D has core arrays, strings, and associative arrays.
>>
>> I agree on this one. So wath is your plan for the D standard library?
>
>Keep incrementally improving it. Is there anything in particular you feel is missing?

One thing I miss a little is continuously sorted collections, as with a tree or similar.  The primary reason is to add elements, print them in order, keep adding, etc.

It seems like this could be done in D fairly simply, since associative arrays (as I understand) already include a binary tree if the hash value fails.  So by defining a hash foo.toHash() that returns the same for all elements, int[foo] could be used as a tree.

The main thing missing would seem to be access to this - i.e. finding ranges without iterating the entire collection.  As in lower_bound / upper_bound in C++ or some variant of foreach-like functionality.

foo[char[]] x;
x.useHash = false; // disables hashing - only valid on an empty array

foreach(char[] k, foo v; x) {
// print all elements in order
}

// advanced version - associative array slicing

foreach(char[] k, foo v; x["allen".."burns") {
// print all elements from allen up to (but not including) burns, in order
}

x.least // lowest key
x.most // highest key

x.least_gt("abc"); // least element greater than "abc"

x[x.least] // element with lowest key

x[x.least_gt("abc")] // first element with key >= "abc"

Kevin

In article <duab09$1arn$1@digitaldaemon.com>, Walter Bright says...

>I see this often and am a bit perplexed by it. What power do you feel is missing?

Maybe you're simply looking at the wrong place. It might not be the language
itself - maybe D is missing a really good and comprehensive tutorial. Imagine
the C++ crowd that wants to migrate to D, and how they struggle to figure out
"the D way to do things". And then, when nothings works as expected, they tend
to say "if D only had [some C++ feature]". Not everyone has fun learning by
searching the web. ;-)
So with a good D tutorial and documentation that has been written with D in mind
from the beginning, D might seem as powerful as it actually is to the people who
are new to D.

As always, just my two cents.
Def

Oskar Linde wrote:
> Bruno Medeiros wrote:
> 
> 
>>Kyle Furlong wrote:
>>
>>>Walter, how technologically complex is implicit template instantiation?
>>>I think the consensus
>>> here is that that is the next feature that everyone wants. I guess my
>>>question is, why did you go through the regex debacle, instead of
>>>working on ITI.
>>
>>I doubt it's the next feature /everyone/ wants, and I pretty sure it's
>>not the next *task done* that everyone wants.
> 
> 
> ITI is important because its absence blocks library development.
> 
> /Oskar

libraries don't neet ITI, java has a great library and for long time it didn't have anything remotely resembling templates (it does now, but that's besides the point).