Re: Should debug{} allow GC?

2016-09-14 Thread Walter Bright via Digitalmars-d

On 9/13/2016 7:40 PM, Manu via Digitalmars-d wrote:

https://issues.dlang.org/show_bug.cgi?id=16492


Thanks!



Re: Should debug{} allow GC?

2016-09-13 Thread Manu via Digitalmars-d
On 14 September 2016 at 10:37, Walter Bright via Digitalmars-d
 wrote:
> On 9/12/2016 6:26 PM, Manu via Digitalmars-d wrote:
>>
>> I'm concerned this would undermind @nogc... If this is supplied in the
>> std library, people will use it, and then you get to a place where you
>> can't rely on @nogc anymore.
>> debug{} blocks sound much safer to me.
>
>
>
> Yeah, I agree. Do you wanna submit an Enhancement Request to Bugzilla on
> this?

https://issues.dlang.org/show_bug.cgi?id=16492


Re: Should debug{} allow GC?

2016-09-13 Thread Walter Bright via Digitalmars-d

On 9/12/2016 6:26 PM, Manu via Digitalmars-d wrote:

I'm concerned this would undermind @nogc... If this is supplied in the
std library, people will use it, and then you get to a place where you
can't rely on @nogc anymore.
debug{} blocks sound much safer to me.



Yeah, I agree. Do you wanna submit an Enhancement Request to Bugzilla on this?


Re: Should debug{} allow GC?

2016-09-12 Thread Manu via Digitalmars-d
On 13 September 2016 at 01:14, Gary Willoughby via Digitalmars-d
 wrote:
> On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
>>
>> I'm having a lot of trouble debugging @nogc functions. I have a number of
>> debug functions that use GC, but I can't call them from @nogc code... should
>> debug{} allow @nogc calls, the same as impure calls?
>
>
> We could with something like this in Phobos:
>
> void assumeNogc(alias Func, T...)(T xs) @nogc {
> import std.traits;
> static auto assumeNogcPtr(T)(T f) if (
> isFunctionPointer!T || isDelegate!T
> ) {
> enum attrs = functionAttributes!T | FunctionAttribute.nogc;
> return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs))
> f;
> };
> assumeNogcPtr(!T)(xs);
> };
>
>
> void main() @nogc
> {
> import std.stdio;
> assumeNogc!writefln("foo %s", 42);
> }
>
> Source: https://dpaste.dzfl.pl/8c5ec90c5b39

I'm concerned this would undermind @nogc... If this is supplied in the
std library, people will use it, and then you get to a place where you
can't rely on @nogc anymore.
debug{} blocks sound much safer to me.


Re: Should debug{} allow GC?

2016-09-12 Thread Walter Bright via Digitalmars-d

On 9/11/2016 12:46 AM, Manu via Digitalmars-d wrote:

I'm having a lot of trouble debugging @nogc functions. I have a number
of debug functions that use GC, but I can't call them from @nogc
code... should debug{} allow @nogc calls, the same as impure calls?



Probably a great suggestion.


Re: Should debug{} allow GC?

2016-09-12 Thread Guillaume Piolat via Digitalmars-d
On Monday, 12 September 2016 at 15:14:19 UTC, Gary Willoughby 
wrote:


Source: https://dpaste.dzfl.pl/8c5ec90c5b39


+1 this would be useful in Phobos, both for the logging case and 
when you find out some extern(C) function hasn't been marked 
@nogc.


Re: Should debug{} allow GC?

2016-09-12 Thread Gary Willoughby via Digitalmars-d

On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
I'm having a lot of trouble debugging @nogc functions. I have a 
number of debug functions that use GC, but I can't call them 
from @nogc code... should debug{} allow @nogc calls, the same 
as impure calls?


We could with something like this in Phobos:

void assumeNogc(alias Func, T...)(T xs) @nogc {
import std.traits;
static auto assumeNogcPtr(T)(T f) if (
isFunctionPointer!T || isDelegate!T
) {
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
	return cast(SetFunctionAttributes!(T, functionLinkage!T, 
attrs)) f;

};
assumeNogcPtr(!T)(xs);
};


void main() @nogc
{
import std.stdio;
assumeNogc!writefln("foo %s", 42);
}

Source: https://dpaste.dzfl.pl/8c5ec90c5b39


Re: Should debug{} allow GC?

2016-09-11 Thread John Colvin via Digitalmars-d

On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
I'm having a lot of trouble debugging @nogc functions. I have a 
number of debug functions that use GC, but I can't call them 
from @nogc code... should debug{} allow @nogc calls, the same 
as impure calls?


Yes please.


Re: Should debug{} allow GC?

2016-09-11 Thread Manu via Digitalmars-d
On 11 September 2016 at 21:26, Q. Schroll via Digitalmars-d
 wrote:
> On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
>>
>> I'm having a lot of trouble debugging @nogc functions. I have a number of
>> debug functions that use GC, but I can't call them from @nogc code... should
>> debug{} allow @nogc calls, the same as impure calls?
>
>
> Generally, there is more to consider. It makes no sense to allow impure
> debug inside a pure function and not to do so for other attributes. For
> nothrow, it is also quite annoying.

I'd make the same argument for nothrow, except that it's easy to just
wrap that in a `try{ mayThrow(); }catch{}`, so I don't think it needs
the same hack because a proper workaround exists.


Re: Should debug{} allow GC?

2016-09-11 Thread Q. Schroll via Digitalmars-d

On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote:
I'm having a lot of trouble debugging @nogc functions. I have a 
number of debug functions that use GC, but I can't call them 
from @nogc code... should debug{} allow @nogc calls, the same 
as impure calls?


Generally, there is more to consider. It makes no sense to allow 
impure debug inside a pure function and not to do so for other 
attributes. For nothrow, it is also quite annoying.


If no one has strong counterarguments, just file an enhancement 
request. Implementation of such should not be too difficult.


Re: Should debug{} allow GC?

2016-09-11 Thread Jonathan M Davis via Digitalmars-d
On Sunday, September 11, 2016 17:46:09 Manu via Digitalmars-d wrote:
> I'm having a lot of trouble debugging @nogc functions. I have a number
> of debug functions that use GC, but I can't call them from @nogc
> code... should debug{} allow @nogc calls, the same as impure calls?

Probably. There might be some problems if a program relies on stuff being
@nogc, and it's compiled with -debug, and it uses code that uses the GC in
debug statements, but it _is_ -debug, and in most cases, I would expect
debug statements to be temporary rather than left in a library that was
distributed (which is the sort of place that it might actually become a
problem). Certainly, on the whole, I think that the reasons for disallowing
use of the GC in debug statements could just as easily be applied to using
impure code in debug statements, and we allow that precisely because it's so
useful for debugging.

- Jonathan M Davis