On 1/20/15 4:10 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> 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.

How's that? The current runtime aborts on memory allocation inside the GC collection routine, it's not a memory safety issue.

-Steve

On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
> 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.
>

You can always put @nogc on the dtor if you want.

-Steve

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!
Not an error, Make it a warning.

On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer wrote:
> How's that? The current runtime aborts on memory allocation inside the GC collection routine, it's not a memory safety issue.

Spurious race conditions in memory deallocation patterns that remain undetected and cause random crashes after deployment are ok? That is not memory safety, it is "memory safety".

The language should prevent this.

On Tue, 20 Jan 2015 21:34:54 +0000
Freddy 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!
> Not an error, Make it a warning.
alas, attribute violations are errors. turning that into warning means that compiler needs new flags and new code to determine if that is "hard restriction" or just "advise". the point of my proposal is that it can be done painlessly with one or two very simple changes in compiler code.

On Tue, 20 Jan 2015 16:30:14 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
> > 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.
> >
> 
> You can always put @nogc on the dtor if you want.
seems that you completely missing my point. (sigh)

On Tuesday, 20 January 2015 at 21:30:14 UTC, Steven Schveighoffer wrote:
> On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
>> 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.
>>
>
> You can always put @nogc on the dtor if you want.
>
> -Steve

I got into habit of always doing that (after painfully learning on my own mistakes...) -- I guess the question of the thread is -- is there a SINGLE reason to not force this at the moment?

On Tuesday, 20 January 2015 at 21:38:50 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 20 Jan 2015 21:34:54 +0000
> Freddy 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!
>> Not an error, Make it a warning.
> alas, attribute violations are errors. turning that into warning means
> that compiler needs new flags and new code to determine if that is
> "hard restriction" or just "advise". the point of my proposal is that
> it can be done painlessly with one or two very simple changes in
> compiler code.

We already have warnings such as:

Warning: toHash() must be declared as extern (D) size_t toHash() const nothrow @safe, not const uint()

It could issue a similar warning to destructors declared without @nogc.

On Tue, 20 Jan 2015 21:37:54 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer wrote:
> > How's that? The current runtime aborts on memory allocation inside the GC collection routine, it's not a memory safety issue.
> 
> Spurious race conditions in memory deallocation patterns that remain undetected and cause random crashes after deployment are ok? That is not memory safety, it is "memory safety".
> 
> The language should prevent this.
and the funniest thing that it is perfectly able to do that! all the code is already there.

On Tue, 20 Jan 2015 21:41:15 +0000
Vladimir Panteleev via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> >> Not an error, Make it a warning.
> > alas, attribute violations are errors. turning that into
> > warning means
> > that compiler needs new flags and new code to determine if that
> > is
> > "hard restriction" or just "advise". the point of my proposal
> > is that
> > it can be done painlessly with one or two very simple changes in
> > compiler code.
> 
> We already have warnings such as:
> 
> Warning: toHash() must be declared as extern (D) size_t toHash() const nothrow @safe, not const uint()
> 
> It could issue a similar warning to destructors declared without @nogc.
ah, i missed that, sorry. sure, if there is already mechanics for this, warning will be ok. i just want the compiler to not remaining silent about the possible issue, and making it error seemed the easiest way.