Hello.

as there is no possibility to doing GC allocations in class destructors, wouldn't it be nice to just force "@nogc" attribute on such dtors?

i know, i know, "this will break alot of code". i'm pretty sure that this will break alot of INVALID code, which better be broken at compile-time anyway.

sure, we have alot of code of pre-@nogc era, and alot of code where authord didn't bother to add attributes at all. so we can introduce "--force-dtor-nogc" CLI arg and document this change, making it opt-in for, say, six month and opt-out after that.

and i know that D devs (Walter at least) are resistant to command-line flags that changing compiler behavior. i don't know how to overcome this. say, by adding "@gc" attribute, which dfix can automatically add?

but i still believe that instead of telling people again and again that they should not allocate in class destructors, we can use computer itself to track and stop this behavior.

let's see how this proposal will be rejected. will there be some sane reasons, or only the good old song about "broken code"? make your bets!

On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via Digitalmars-d wrote:
> Hello.
>
> as there is no possibility to doing GC allocations in class
> destructors, wouldn't it be nice to just force "@nogc" attribute on
> such dtors?
>
> i know, i know, "this will break alot of code". i'm pretty sure that
> this will break alot of INVALID code, which better be broken at
> compile-time anyway.
>
> sure, we have alot of code of pre-@nogc era, and alot of code where
> authord didn't bother to add attributes at all. so we can introduce
> "--force-dtor-nogc" CLI arg and document this change, making it opt-in
> for, say, six month and opt-out after that.
>
> and i know that D devs (Walter at least) are resistant to command-line
> flags that changing compiler behavior. i don't know how to overcome
> this. say, by adding "@gc" attribute, which dfix can automatically add?
>
> but i still believe that instead of telling people again and again that
> they should not allocate in class destructors, we can use computer
> itself to track and stop this behavior.
>
> let's see how this proposal will be rejected. will there be some sane
> reasons, or only the good old song about "broken code"? make your bets!

Isn't this just an implementation detail of the current garbage collector? If so, then we shouldn't tie language semantics to it, as it could change.

On Tue, 20 Jan 2015 18:17:56 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via Digitalmars-d wrote:
> > Hello.
> >
> > as there is no possibility to doing GC allocations in class
> > destructors, wouldn't it be nice to just force "@nogc"
> > attribute on
> > such dtors?
> >
> > i know, i know, "this will break alot of code". i'm pretty sure
> > that
> > this will break alot of INVALID code, which better be broken at
> > compile-time anyway.
> >
> > sure, we have alot of code of pre-@nogc era, and alot of code
> > where
> > authord didn't bother to add attributes at all. so we can
> > introduce
> > "--force-dtor-nogc" CLI arg and document this change, making it
> > opt-in
> > for, say, six month and opt-out after that.
> >
> > and i know that D devs (Walter at least) are resistant to
> > command-line
> > flags that changing compiler behavior. i don't know how to
> > overcome
> > this. say, by adding "@gc" attribute, which dfix can
> > automatically add?
> >
> > but i still believe that instead of telling people again and
> > again that
> > they should not allocate in class destructors, we can use
> > computer
> > itself to track and stop this behavior.
> >
> > let's see how this proposal will be rejected. will there be
> > some sane
> > reasons, or only the good old song about "broken code"? make
> > your bets!
> 
> Isn't this just an implementation detail of the current garbage collector? If so, then we shouldn't tie language semantics to it, as it could change.
how likely this to be changed? is there *any* chances of that in 2015? 2016? and why we can't just remove that restriction when new GC will be implemented? removing the "@nogc" requirement on class dtors will break *nothing* *at* *all*. yet adding it now, while we don't have that new GC, will prevent alot of bugs that can slip in crack.

btw, you won the prize of not talking about "broken code"! sadly, i forgot to setup the prizes... anyway, thanks for sane argument.

On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via Digitalmars-d wrote:
> how likely this to be changed? is there *any* chances of that in 2015?
> 2016? and why we can't just remove that restriction when new GC will be
> implemented? removing the "@nogc" requirement on class dtors will break
> *nothing* *at* *all*. yet adding it now, while we don't have that new
> GC, will prevent alot of bugs that can slip in crack.
>
> btw, you won the prize of not talking about "broken code"! sadly, i
> forgot to setup the prizes... anyway, thanks for sane argument.

Is it that subtle of a bug? Your program crashes once, you go on the forums and find the answer, and then you know never to do it again.

On Tuesday, 20 January 2015 at 20:25:15 UTC, Meta wrote:
> Is it that subtle of a bug? Your program crashes once, you go on the forums and find the answer, and then you know never to do it again.

Furthermore, this is something that seems like it'd be incredibly simple to add to dscanner (of course, everyone doesn't use dscanner). Someone who wants to avoid hidden allocations in a destructor will mark all their class destructors @nogc anyway, so enforcing it seems like it wouldn't add much value over what can already be done.

On Tue, 20 Jan 2015 20:25:13 +0000
Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 18:25:42 UTC, ketmar via Digitalmars-d wrote:
> > how likely this to be changed? is there *any* chances of that
> > in 2015?
> > 2016? and why we can't just remove that restriction when new GC
> > will be
> > implemented? removing the "@nogc" requirement on class dtors
> > will break
> > *nothing* *at* *all*. yet adding it now, while we don't have
> > that new
> > GC, will prevent alot of bugs that can slip in crack.
> >
> > btw, you won the prize of not talking about "broken code"!
> > sadly, i
> > forgot to setup the prizes... anyway, thanks for sane argument.
> 
> Is it that subtle of a bug? Your program crashes once, you go on the forums and find the answer, and then you know never to do it again.
and then you will inevitably do it again and again, 'cause compiler is silent about allocations in destructor. and you may accidentally call functions from another libraries which allocating. and then it can be hidden behind some `if`'s, so it will not crash for you, but will crash for someone other.

and all that mess can be avoided just by enforcing the one simple rule, which compiler is perfectly able to check.

> Someone who wants to avoid hidden allocations in a destructor will mark all their class destructors @nogc anyway
that if he KNOWS about hidden traps of allocating in class destructors. this way we can stop doing any checking at all, 'cause someone who knows what he wants will write the code to check what he wants anyway.

On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:

> and all that mess can be avoided just by enforcing the one simple rule,
> which compiler is perfectly able to check.

I think the current situation is fine.

1. There are functions that sometimes allocate. I don't want to forbid those, or force someone to write @nogc versions.
2. One can invoke destructors without being inside the GC.

This seems like a good job for a lint tool.

-Steve

On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
> 
> > and all that mess can be avoided just by enforcing the one simple rule, which compiler is perfectly able to check.
> 
> I think the current situation is fine.
> 
> 1. There are functions that sometimes allocate. I don't want to forbid
> those, or force someone to write @nogc versions.
> 2. One can invoke destructors without being inside the GC.
> 
> This seems like a good job for a lint tool.
my point is that those who need to run lint doesn't do that. enforcing "@nogc" on class dtors protecting people who are relatively new to D, and used to do (maybe invisible) allocations in C++ dtors, for example. yes, this is bad practice even in C++, but it mostly works there. so they coming to D and often just doesn't know that class dtors are very special beasts.

to give seasoned programmer some control it's enough to introduce `@gc` attribute. there are periodical requests for "cancelling attributes" in NG, so it's a perfect excuse to both make compiler more helpful for newcomers (yes, it's better to see error message in compile-time than to get some strange crashes in run-time), and to introduce "cancelling attrs".

On Tue, 20 Jan 2015 15:51:17 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

p.s. another point is that all mechanics compiler needs for doing such checks is already there, so it's not a huge change to compiler codebase. it's not something that requires adding a whole new analysis code.

On Tuesday, 20 January 2015 at 20:51:18 UTC, Steven Schveighoffer wrote:
> On 1/20/15 3:39 PM, ketmar via Digitalmars-d wrote:
>
>> and all that mess can be avoided just by enforcing the one simple rule,
>> which compiler is perfectly able to check.
>
> I think the current situation is fine.

In other words, memory safety is no longer a goal.

Excellent!  I hope that means the effort wasted on memory safety will be used to address the other weak spots instead, such as the syntax.