On 1/21/15 6:03 PM, Paolo Invernizzi wrote:
> On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven Schveighoffer wrote:
>> On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
>>> On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven Schveighoffer
>>> wrote:
>>>> On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
>>>> If he does it wrong, it gives him a stack trace on where to look. What
>>>> is different here than any other programming error?
>>>
>>> Are you suggesting that newcomers should learn D by discovering it day
>>> by day from stack traces?
>>
>> No, I was saying if something causes an exception/error, it is a
>> programming error, and there just isn't any way for a compiler to
>> prevent people from making *any* mistakes.
>>
>> But calling sometimes-allocating functions inside a dtor that don't
>> allocate when you call them *that* time shouldn't be banned by the
>> compiler.
>
> You can't ban them, either now with an annotated @nogc destructor:
> SetFunctionAttributes.

Right, but the runtime will still catch it if it allocates. I think the correct place to check it is where it's checked now.

-Steve

On 1/21/15 3:45 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 21 January 2015 at 03:03:50 UTC, Steven Schveighoffer wrote:
>> It's neither spurious, nor a race condition.
>
> How can you say that a priori?

When the GC collects, it doesn't allow memory allocation. This is not a race condition, it's simply a fact of programming with D. It's not unintentional or spurious.

A race condition can LEAD to this being triggered, but the abort itself is not a race condition. And forcing a default of @nogc will not fix this.

You said "spurious race conditions in memory deallocation patterns that remain undetected and cause random crashes after deployment are ok"

If you didn't mean that we were *causing* spurious race conditions by allowing non-@nogc calls inside a destructor, and just meant that spurious race conditions were not ok, I agree with you.

-Steve

On Thursday, 22 January 2015 at 11:50:55 UTC, Steven Schveighoffer wrote:
> On 1/21/15 6:03 PM, Paolo Invernizzi wrote:
>> On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven Schveighoffer wrote:
>>> On 1/21/15 3:37 AM, Paolo Invernizzi wrote:
>>>> On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven Schveighoffer
>>>> wrote:
>>>>> On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
>>>>> If he does it wrong, it gives him a stack trace on where to look. What
>>>>> is different here than any other programming error?
>>>>
>>>> Are you suggesting that newcomers should learn D by discovering it day
>>>> by day from stack traces?
>>>
>>> No, I was saying if something causes an exception/error, it is a
>>> programming error, and there just isn't any way for a compiler to
>>> prevent people from making *any* mistakes.
>>>
>>> But calling sometimes-allocating functions inside a dtor that don't
>>> allocate when you call them *that* time shouldn't be banned by the
>>> compiler.
>>
>> You can't ban them, either now with an annotated @nogc destructor:
>> SetFunctionAttributes.
>
> Right, but the runtime will still catch it if it allocates. I think the correct place to check it is where it's checked now.
>
> -Steve

I have troubles following your reasoning, so I must have lost something.

- the proposal was to have a default @nogc in the dtor.
- the rebuttal was that "functions that don't allocate when you call them *THAT TIME* shouldn't be banned".
- I just noticed that also with destructor marked @nogc, if you know and trust a @gc function you can use it with the help of traits and casts.
- the reply was that the runtime will catch it "if it allocate", that I don't understand what is related with the notice, or with the original proposal.

I don't see nothing strange in turning into the default the CT check about avoiding GC allocations in destructors, that's the vast majority of uses cases, and force an explicit cast/traits if the programmer want to mark in the code "hey, I know that using the GC in the DTOR is a bad, but trust this cast, in any case If I'm wrong the runtime will signal you".

Sorry if I feel pedantic in the discussion, but being a not native english speaker (and a little in a hurry when writing in the forums) I just wanted to be clear in my exposition... ;-)

--
Paolo

On 1/22/15 8:42 AM, Paolo Invernizzi wrote:
>>> You can't ban them, either now with an annotated @nogc destructor:
>>> SetFunctionAttributes.
>>
>> Right, but the runtime will still catch it if it allocates. I think
>> the correct place to check it is where it's checked now.
>>
>
> I have troubles following your reasoning, so I must have lost something.
>
> - the proposal was to have a default @nogc in the dtor.
> - the rebuttal was that "functions that don't allocate when you call
> them *THAT TIME* shouldn't be banned".
> - I just noticed that also with destructor marked @nogc, if you know and
> trust a @gc function you can use it with the help of traits and casts.
> - the reply was that the runtime will catch it "if it allocate", that I
> don't understand what is related with the notice, or with the original
> proposal.

Missing from this list is that -- if it isn't broke don't fix it :)

I will note that I think if @nogc was the default, I would be in favor of keeping it that way. In order to justify a breaking change like this, there needs to be a good enough reason. IMO (and really, this is my opinion, I'm not the ultimate gatekeeper here) the bar has not been cleared.

> I don't see nothing strange in turning into the default the CT check
> about avoiding GC allocations in destructors, that's the vast majority
> of uses cases, and force an explicit cast/traits if the programmer want
> to mark in the code "hey, I know that using the GC in the DTOR is a bad,
> but trust this cast, in any case If I'm wrong the runtime will signal you".

In the vast majority of cases, nobody adds a dtor, or they use dtors for their intended purpose (deallocating non-GC resources) and everything works fine. And the runtime catches any slips with an appropriate handling (abort instead of corrupt memory).

> Sorry if I feel pedantic in the discussion, but being a not native
> english speaker (and a little in a hurry when writing in the forums) I
> just wanted to be clear in my exposition... ;-)

I understand your opinion, I just don't think it's worth the trouble and breaking of code.

-Steve

On Thursday, 22 January 2015 at 11:58:13 UTC, Steven Schveighoffer wrote:
> A race condition can LEAD to this being triggered, but the abort itself is not a race condition. And forcing a default of @nogc will not fix this.

Why not? If you have a race condition that leads a memory leak when using explicit deallocation, then that leak will lead to destructor being run by the collector. Which will fail if the destructor gc-allocates. GC is meant to make allocation safer, not less safe.

On Thursday, 22 January 2015 at 14:07:31 UTC, Steven Schveighoffer wrote:
> resources) and everything works fine. And the runtime catches any slips with an appropriate handling (abort instead of corrupt memory).

Runtime errors that could have been a compile time error should always be caught at compile time. Spurious runtime errors are just as bad as null pointer accesses.

On 1/22/15 11:10 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 22 January 2015 at 14:07:31 UTC, Steven Schveighoffer wrote:
>> resources) and everything works fine. And the runtime catches any
>> slips with an appropriate handling (abort instead of corrupt memory).
>
> Runtime errors that could have been a compile time error should always
> be caught at compile time. Spurious runtime errors are just as bad as
> null pointer accesses.

Well, code that does not have errors should not be caught at compile time. I count writeln("in dtor") as one of them.

You may disagree, but we aren't making progress on this.

-Steve

On 1/22/15 10:59 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 22 January 2015 at 11:58:13 UTC, Steven Schveighoffer wrote:
>> A race condition can LEAD to this being triggered, but the abort
>> itself is not a race condition. And forcing a default of @nogc will
>> not fix this.
>
> Why not? If you have a race condition that leads a memory leak when
> using explicit deallocation, then that leak will lead to destructor
> being run by the collector. Which will fail if the destructor
> gc-allocates. GC is meant to make allocation safer, not less safe.

Disallowing compilation of the dtor does not fix the race condition. We are no closer to race-free code here.

What you are basically saying is, race conditions are OK, as long as they don't allocate memory in dtors.

-Steve

On Thursday, 22 January 2015 at 16:53:10 UTC, Steven Schveighoffer wrote:
> Disallowing compilation of the dtor does not fix the race condition. We are no closer to race-free code here.
>
> What you are basically saying is, race conditions are OK, as long as they don't allocate memory in dtors.

Most large programs will be deployed with some minor bugs.

What I basically say is that a program that would run fine with manual memory management and some occasional leaks, will crash if you use alloc from the gc heap instead of the plain heap.

"Ola Fosheim Grøstad" " wrote in message news:ncuttyurxztvrziuynxj@forum.dlang.org...

> Runtime errors that could have been a compile time error should always be caught at compile time. Spurious runtime errors are just as bad as null pointer accesses.

Allocating in a dtor shouldn't be a runtime or compile-time error, it should just work.