Am 03.05.2014 10:57, schrieb froglegs:
>
>> feels like writing C++ with C# syntax.
>
>   Ahem. C++ has RAII k thanks.  C++ > C# Proof.

Which does not work across threads, relies on stack allocations and has issues if cleaning a resource implies having a not handled exception on the destructor of the RAII class.

I rather make use of "using" and FP resource handling via lambdas.

--
Paulo

On 5/3/14, 1:49 AM, Benjamin Thaut wrote:
> 2) Quit D. (which is becomeing more and more an option when reading the
> recent news group discussions.)

The entire idea of starting these discussions is to gather a sense of shared vision with the community on the best direction to follow.

I'm trying to steer things so as to gain the maximum benefit from each potential breakage. In wake of that, it seems incongruous that first you ask for even larger breaking changes to the language, but then consider quitting it entirely on account of changes being too disruptive.

Anyhow, just to clarify, it seems like eliminating destructor calls during GC is not a viable option. I'll define std.allocator to allow users to define such a GC if they so want, without prescribing either policy.


Andrei

On Sat, May 03, 2014 at 11:12:36AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> Anyhow, just to clarify, it seems like eliminating destructor calls during GC is not a viable option. I'll define std.allocator to allow users to define such a GC if they so want, without prescribing either policy.
[...]

Thank you. ;-)

On that note, it would be very nice if we could clearly define when dtor calls will / will not happen. As someone else said, to an end-user of D it is hard to accept that basic language constructs like arrays and dtors, when used together, fail to function in an expected way (without understanding what goes on underneath the hood, e.g. why dtors of array elements may not get called). Ideally, the language should be designed such that these obvious combinations of language constructs should either Just Work(tm), or not be allowed, or require explicit annotation (so that the user knows something unexpected might happen).

But, since we're not in an ideal world, the very least we could do is to clearly define exactly which combinations of language constructs may behave in an unexpected way, and document them up front in a prominent place.

Otherwise, we risk turning off potential users -- I can just imagine a newbie to D writing something like "File[] files;" and then wondering why things don't work as expected, and then throwing in the towel and say "what a lousy language, let me move on to another one".

And on that note, I'd like to say that my previous posts about prohibiting structs with dtors as class members (if we were to move in the direction of getting rid of class dtors altogether, which happily isn't the case anymore) were primarily motivated by the desire to see more of D obeying the principle of least surprise: two built-in language constructs, structs with dtors and class members, when combined together, *should* Just Work -- one expects that dtors will get called with the struct goes out of scope, by the very definition of a dtor, so one would expect they will still get cleaned up when they happen to be a class member. The fact that they don't is a surprise, which then requires some other way of warning the user that things aren't what they might be expected to be. Maybe my proposed solutions suck, but the underlying problem still needs to be addressed. The scope of the problem is smaller, now that we're no longer killing off class dtors, but nevertheless something needs to be done about it.

I think this is one area where D could use a lot of improvement. There are currently a handful of glaring holes where built-in language constructs interact with each other in unexpected or buggy ways.  While it may feel like mole-whacking (because of combinatorial explosion as you add features to the language), I think it's very important to address, since otherwise it gives new users an impression (not necessarily well-founded, but first impressions do matter) of sloppy language design. The seams show through, and it's not very nice. One example is the interaction of dtors with the GC. Another example is the interaction of const/immutable with AA's. Another is the interaction of @disabled with .init and other generic code. It seems that almost every non-trivial use of these features is like navigating a minefield -- there are so many gotchas, unexpected behaviours, and implementation bugs, that it's embarrassing. Other areas include shared, though I don't have first-hand experience of that so I can't speak for it.

While proposing radical changes may be exhilarating, in the long run that may do more harm than good. What these features need is some TLC and detailed fine-tuning within the current, already-existing framework.

TL;DR: I'd like to see more attention paid to the details of how language features interact with each other, and fixing those issues, rather than inventing more radical new ideas that may or may not solve the problem, and more likely than not will introduce new problems to add to our already-long list of issues.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
> If a class has at least one member with a
> destructor, the compiler might need to generate a destructor for the class.

And in fact that's what dmd does.

On 5/3/14, 12:40 PM, Walter Bright wrote:
> On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
>> If a class has at least one member with a
>> destructor, the compiler might need to generate a destructor for the
>> class.
>
> And in fact that's what dmd does.

Which suggests a simple solution for calling destructors for structs and arrays:

* Lower new for structs to return:

new S;
->
return &(new class { S member; }).member;

* Lower array construction similarly.

Then voila, the anonymous classes will destroy structs and arrays appropriately.


Andrei

On 5/3/2014 6:44 PM, Andrei Alexandrescu wrote:
> On 5/3/14, 12:40 PM, Walter Bright wrote:
>> On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
>>> If a class has at least one member with a
>>> destructor, the compiler might need to generate a destructor for the
>>> class.
>>
>> And in fact that's what dmd does.
>
> Which suggests a simple solution for calling destructors for structs and
> arrays:
>
> * Lower new for structs to return:
>
> new S;
> ->
> return &(new class { S member; }).member;
>
> * Lower array construction similarly.
>
> Then voila, the anonymous classes will destroy structs and arrays
> appropriately.
>

Uhh, but doesn't this completely break as soon as class dtors go away?

On Sat, 03 May 2014 22:44:39 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 5/3/2014 6:44 PM, Andrei Alexandrescu wrote:
> > On 5/3/14, 12:40 PM, Walter Bright wrote:
> >> On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
> >>> If a class has at least one member with a
> >>> destructor, the compiler might need to generate a destructor for
> >>> the class.
> >>
> >> And in fact that's what dmd does.
> >
> > Which suggests a simple solution for calling destructors for structs and arrays:
> >
> > * Lower new for structs to return:
> >
> > new S;
> > ->
> > return &(new class { S member; }).member;
> >
> > * Lower array construction similarly.
> >
> > Then voila, the anonymous classes will destroy structs and arrays appropriately.
> >
>
> Uhh, but doesn't this completely break as soon as class dtors go away?

Based on other comments, I think that Andrei has been convinced that class destructors can't go away at this point and that there certainly isn't any consensus that it would even be desirable for them to go away (though what he'd choose to do if we could break code willy-nilly, I don't know). So, this particular proposal is presumably done with the idea that class destructors are here to stay. Rather, it's trying to make it so that the destructors for structs on the heap get run unlike now - which is a much better direction to try and go IMHO.

- Jonathan M Davis

On Sat, May 3, 2014 at 3:49 AM, Benjamin Thaut via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
> 2) Quit D. (which is becomeing more and more an option when reading the
> recent news group discussions.)
>
> --
> Kind Regards
> Benjamin Thaut
>

I never thought I would say this, but I have begun to move away from D.  I know others who are doing the same.  The advantages D has over other languages are slowly diminishing.  Plus, as it is, D is just as complex and complicated as C++, if not more.  Couple that with the never-ending bugs and weak development process, there isn't much confidence in choosing D.

One of the main and crippling issues D has is its development process.  Its inner circle, mainly Walter, Andrei and a few others, do not seem to have a good understanding of FOSS development process.  For example, Rust is only a few years old and much younger than D, but it has a greater number of contributors, and its rate of contributors seems to be growing faster.  D has failed at recruitment; I always read people (mainly the inner circle) mention the everlasting low-hanging fruits.  Well, if the number of contributors was growing then the number of low-hanging fruits would be decreasing.  Andrei recently introduced the bounty system, which not only is an insult to those who contribute to FOSS, but it also goes to show that he really doesn't understand how and why people contribute to FOSS without ever asking to be compensated.

Last but not least, currently there are two main ways for new features to make it into D/Phobos: you either have to belong to the inner circle, or have to represent some corporation that's doing something with D.  I don't remember seeing a feature that was added to D/Phobos with some on/off switch that people could try in the next release, and then send in feedback.  You're in a much better position to make a decision about a feature if the users have actually used it and reported feedback.  Ahh, and don't get me started on Phobos review process; it's a joke, it's bogus and just pathetic.

If D had a sound development process, I don't think we would be having the problems that we have today.

On Sat, 03 May 2014 15:44:03 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 5/3/14, 12:40 PM, Walter Bright wrote:
> > On 5/1/2014 7:59 AM, Andrei Alexandrescu wrote:
> >> If a class has at least one member with a
> >> destructor, the compiler might need to generate a destructor for
> >> the class.
> >
> > And in fact that's what dmd does.
>
> Which suggests a simple solution for calling destructors for structs and arrays:
>
> * Lower new for structs to return:
>
> new S;
> ->
> return &(new class { S member; }).member;
>
> * Lower array construction similarly.
>
> Then voila, the anonymous classes will destroy structs and arrays appropriately.

This might be a good approach, though I confess that it strikes me as rather
weird to wrap structs in classes like that. It also leaves open the question
of how to deal with structs that are newed directly rather than put in an
array. _Those_ really need to be destroyed properly as well. And unless
you're suggesting that S* effectively become a pointer to a struct within
an anonymous class in all cases, not only would this not work for structs
which were newed up directly on the heap, but I'd be worried about what would
happen when someone did something like &arr[5] with an array of structs. Would
they get a pointer to a class or a struct?

It was my understanding that some of what Rainer Schutze did with his precise GC involved adding RTInfo which could make it possible to run struct destructors for structs that were newed up directly on the heap. If that is indeed the case, then I would think that we could use that for arrays of structs as well.

- Jonathan M Davis

On 5/3/14, 8:48 PM, Caligo via Digitalmars-d wrote:
> On Sat, May 3, 2014 at 3:49 AM, Benjamin Thaut via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     2) Quit D. (which is becomeing more and more an option when reading
>     the recent news group discussions.)
>
>     --
>     Kind Regards
>     Benjamin Thaut
>
>
> I never thought I would say this, but I have begun to move away from D.
>   I know others who are doing the same.  The advantages D has over other
> languages are slowly diminishing.  Plus, as it is, D is just as complex
> and complicated as C++, if not more.  Couple that with the never-ending
> bugs and weak development process, there isn't much confidence in
> choosing D.
>
> One of the main and crippling issues D has is its development process.
>   Its inner circle, mainly Walter, Andrei and a few others, do not seem
> to have a good understanding of FOSS development process.  For example,
> Rust is only a few years old and much younger than D, but it has a
> greater number of contributors, and its rate of contributors seems to be
> growing faster.  D has failed at recruitment; I always read people
> (mainly the inner circle) mention the everlasting low-hanging fruits.
>   Well, if the number of contributors was growing then the number of
> low-hanging fruits would be decreasing.  Andrei recently introduced the
> bounty system, which not only is an insult to those who contribute to
> FOSS, but it also goes to show that he really doesn't understand how and
> why people contribute to FOSS without ever asking to be compensated.

Mostly good points, but the bountysource program is an experiment by Facebook, not by myself. And (without me trying to speak on Facebook's behalf) it would be difficult to argue that Facebook doesn't understand FOSS or is out there to insult contributors. We're just experimenting with various angles.

> Last but not least, currently there are two main ways for new features
> to make it into D/Phobos: you either have to belong to the inner circle,
> or have to represent some corporation that's doing something with D.  I
> don't remember seeing a feature that was added to D/Phobos with some
> on/off switch that people could try in the next release, and then send
> in feedback.  You're in a much better position to make a decision about
> a feature if the users have actually used it and reported feedback.

The on/off switch may be a nice idea in the abstract but is hardly the perfect recipe to good language feature development; otherwise everybody would be using it, and there's not overwhelming evidence to that. (I do know it's been done a few times, such as the (in)famous "new scoping rule of the for statement" for C++ which has been introduced as an option by VC++.)

I wonder how you've gotten the perception that one needs to be a member of the inner circle mafia to get things into D. Today's major contributors to D came from all over, without any preexisting relationship to anyone else, and their admission ticket has been getting work done. Could you please get into detail on how you view things? (I tried to look over your past posts to see a pattern of rejected contributions, but didn't find such.)

>   Ahh, and don't get me started on Phobos review process; it's a joke,
> it's bogus and just pathetic.

Actually I'd love to get you started so I'd understand your angle better. I'm sure we can do a lot better. One good thing Phobos reviews have done since we initiated them has been to prevent bad artifacts to make it into the library. We'd love to make it better. From what I saw witnessing similar processes (C++, Boost, Python, Scala) - they all have some sense of awkward self-importance to them upon the first look. I think that's the way such things work.

> If D had a sound development process, I don't think we would be having
> the problems that we have today.

I've discussed development process with a number of people who participated at such. They mentioned that until you get teams paid to work on the respective system (OS, language, framework etc) it all works on the basis of people doing things to scratch an itch they have. The critical mass is attained when there are enough people to cover a large enough itching area :o). If telling people what to work on on their free time works, I haven't succeeded at it and don't know anyone who has.


Andrei