On Friday, 29 August 2014 at 03:07:06 UTC, Jonathan M Davis wrote:
> and that we don't normally provide flags to revert changes in behavior

Exactly the culture I am trying to change here.

Either companion flag in compiler that prints places where structs are going to be "destructored" now or runtime switch for druntime that disable new behavior if set. Pretty much anything that can show users that we care.

On Friday, 29 August 2014 at 03:32:45 UTC, Andrei Alexandrescu wrote:
> On 8/28/14, 8:07 PM, Jonathan M Davis wrote:
>> Since this is in the library, not the compiler, I'm not sure how you'd
>> do that (have the compiler specific a version identifier for it?), but
>> considering how broken the behavior was before and that we don't
>> normally provide flags to revert changes in behavior, I'd argue that
>> anyone who has problems with it should just use the previous version of
>> the compiler until they're ready to update their code.
>
> I'd say the impact is too large to leave things at that. How about a function call callStructDestructorsDuringGC(bool) - yes, that long - that people can place in main() if they're having trouble?

I'm okay with that, though given that this is almost exclusively fixing bugs and isn't particularly likely to create many, I'm not at all convinced that it's that big a deal.

- Jonathan M Davis

On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
> Dear community, are you ready for this?

Yes.

On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
> Dear community, are you ready for this?
>
> https://issues.dlang.org/show_bug.cgi?id=2834
> https://github.com/D-Programming-Language/druntime/pull/864
>
> We must do it, and the way I see it the earlier the better. Shall we do it in 2.067?
>
> This is a significant change of behavior. Should we provide a temporary flag or attribute to disable it?
>
>
> Thanks,
>
> Andrei

Questions:
- Can and will this work for arrays of structs?
- When doing manual GC allocations (for whatever reason), how can we later tell the GC what destructor to call?

These questions combined are really aimed at Appender: I'm curious at if and how any changes will have to be made to it.

Also question: Will this play nice wit exiting code that manually destroys GC allocated structs?

On 29/08/14 04:21, Andrei Alexandrescu wrote:
> Dear community, are you ready for this?
>
> https://issues.dlang.org/show_bug.cgi?id=2834
> https://github.com/D-Programming-Language/druntime/pull/864

Does this has the same issues as destructors for classes, i.e. not guaranteed to run?

-- 
/Jacob Carlborg

On Thu, 28 Aug 2014 19:21:04 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> Dear community, are you ready for this?
yes, yes and yes!

On Friday, 29 August 2014 at 02:38:54 UTC, H. S. Teoh via Digitalmars-d wrote:
> Maybe a more relevant question might be, is there any existing code that
> *isn't* broken by structs not being destructed? (D-structed, har har.)

Well, this new change *could* greatly increase the amount of "allocation during destruction" errors we are getting. I've seen a fair share of these in learn, whereas a class destructor allocates.

Structs will now also be more vulnerable to this problem too. I wouldn't be surprised if this pull instantaneously introduced a fair amount of breakage in client code.

On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
> Dear community, are you ready for this?

Yes! Whatever needs be done.

On 8/29/14, ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
>> Dear community, are you ready for this?
>
> Yes! Whatever needs be done.

Yeah destructors are a sore pain when they're unreliable. "May or may not be called" is just an awful semantic.

On Friday, 29 August 2014 at 09:08:07 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 8/29/14, ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu
>> wrote:
>>> Dear community, are you ready for this?
>>
>> Yes! Whatever needs be done.
>
> Yeah destructors are a sore pain when they're unreliable. "May or may
> not be called" is just an awful semantic.

That won't really change though, will it? AFAIK, it'll become: "will eventually be called at some unspecified point it time. The program may terminate before that happens, at which point, the destructor will never be called."

...right?