On 10/21/14 3:24 PM, Walter Bright wrote:
> On 10/21/2014 12:15 PM, Gary Willoughby wrote:
>> On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
>> wrote:
>>> Yep, you can just turn off purity when it gets in the way.
>>>
>>> -Steve
>>
>> Please raise a ticket for this.
>
> That was done deliberately - it's a feature. It enables things like
> debugging printf's to be inserted into pure functions.

Right. But my understanding was that was only when you were actually compiling with debug enabled. I didn't expect it to be a feature to be able to do this without debug enabled, as it currently is.

-Steve

Am Tue, 21 Oct 2014 22:33:02 -0400
schrieb Steven Schveighoffer <schveiguy@yahoo.com>:

> On 10/21/14 3:24 PM, Walter Bright wrote:
> > On 10/21/2014 12:15 PM, Gary Willoughby wrote:
> >> On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer wrote:
> >>> Yep, you can just turn off purity when it gets in the way.
> >>>
> >>> -Steve
> >>
> >> Please raise a ticket for this.
> >
> > That was done deliberately - it's a feature. It enables things like debugging printf's to be inserted into pure functions.
> 
> Right. But my understanding was that was only when you were actually compiling with debug enabled. I didn't expect it to be a feature to be able to do this without debug enabled, as it currently is.
> 
> -Steve

You might be surprised that -debug doesn't enable anything
special. It is just a shortcut for setting the debug level to
1 (a shortcut for -debug=1). Likewise debug statements are a
shortcut for debug(1) {…}. This is also analogous to -version.

-- 
Marco

On Wednesday, 22 October 2014 at 11:13:35 UTC, Marco Leise wrote:
> You might be surprised that -debug doesn't enable anything
> special. It is just a shortcut for setting the debug level to
> 1 (a shortcut for -debug=1). Likewise debug statements are a
> shortcut for debug(1) {…}. This is also analogous to -version.

On a related note, how do you provide multiple execution paths based on cpuid without making the code dirty?

In C I guess a trick would simply be to recompile the compilation unit twice with different settings and a macro definition on the command line to change the function name.

This is relevant for code where you want to provide a single binary for various CPU generations (AVX512, SSE, MMX)…

On 10/22/14 7:23 AM, Marco Leise wrote:
> Am Tue, 21 Oct 2014 22:33:02 -0400
> schrieb Steven Schveighoffer <schveiguy@yahoo.com>:
>
>> On 10/21/14 3:24 PM, Walter Bright wrote:
>>> On 10/21/2014 12:15 PM, Gary Willoughby wrote:
>>>> On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
>>>> wrote:
>>>>> Yep, you can just turn off purity when it gets in the way.
>>>>>
>>>>> -Steve
>>>>
>>>> Please raise a ticket for this.
>>>
>>> That was done deliberately - it's a feature. It enables things like
>>> debugging printf's to be inserted into pure functions.
>>
>> Right. But my understanding was that was only when you were actually
>> compiling with debug enabled. I didn't expect it to be a feature to be
>> able to do this without debug enabled, as it currently is.
>
> You might be surprised that -debug doesn't enable anything
> special. It is just a shortcut for setting the debug level to
> 1 (a shortcut for -debug=1). Likewise debug statements are a
> shortcut for debug(1) {…}. This is also analogous to -version.
>

I am surprised. So you can actually enable all debug code permanently.

I think debug=... statement should be made illegal.

-Steve

On Wednesday, 22 October 2014 at 13:58:44 UTC, Steven Schveighoffer wrote:
> I am surprised. So you can actually enable all debug code permanently.
>
> I think debug=... statement should be made illegal.
>
> -Steve

I'd agree with that to be honest. It seems odd to allow this in code. I can understand the rationale for doing unpure things in a pure function in debug mode but that mode should be specified on the command line, not in code. Like you say, you can enable debug mode permanently in code.

On Wed, 22 Oct 2014 17:04:41 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Wednesday, 22 October 2014 at 13:58:44 UTC, Steven Schveighoffer wrote:
> > I am surprised. So you can actually enable all debug code permanently.
> >
> > I think debug=... statement should be made illegal.
> >
> > -Steve
> 
> I'd agree with that to be honest. It seems odd to allow this in code. I can understand the rationale for doing unpure things in a pure function in debug mode but that mode should be specified on the command line, not in code. Like you say, you can enable debug mode permanently in code.
i think that compiler should emit warning on such code. it can be handy to do such things, but let compiler warn us that "debug=" is not very safe thing to do.

On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On a related note, how do you provide multiple execution paths based on cpuid
> without making the code dirty?

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d

On Wednesday, 22 October 2014 at 19:24:54 UTC, Walter Bright wrote:
> On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On a related note, how do you provide multiple execution paths based on cpuid
>> without making the code dirty?
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d

Hmm… that looks a bit complicated. I was thinking about compiling the same function with different backend settings, so you get myfunc_AVX() and myfunc_SSE() from the same function body.

On Tuesday, October 21, 2014 22:33:02 Steven Schveighoffer via Digitalmars-d
wrote:
> On 10/21/14 3:24 PM, Walter Bright wrote:
> > On 10/21/2014 12:15 PM, Gary Willoughby wrote:
> >> On Tuesday, 21 October 2014 at 17:25:37 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >>> Yep, you can just turn off purity when it gets in the way.
> >>>
> >>> -Steve
> >>
> >> Please raise a ticket for this.
> >
> > That was done deliberately - it's a feature. It enables things like
> > debugging printf's to be inserted into pure functions.
>
> Right. But my understanding was that was only when you were actually
> compiling with debug enabled. I didn't expect it to be a feature to be
> able to do this without debug enabled, as it currently is.

Yeah, being able to just enable the debug blocks from within the code like
that seems questionable to me and has nothing to do with debug blocks
disabling pure functions. It just makes for a nastier side effect when debug
blocks are enabled within the code rather than via the command-line.

- Jonathan M Davis

On 10/22/2014 12:44 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 22 October 2014 at 19:24:54 UTC, Walter Bright wrote:
>> On 10/22/2014 4:30 AM, "Ola Fosheim Grøstad"
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> On a related note, how do you provide multiple execution paths based on cpuid
>>> without making the code dirty?
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arrayfloat.d
>>
>
> Hmm… that looks a bit complicated. I was thinking about compiling the same
> function with different backend settings, so you get myfunc_AVX() and
> myfunc_SSE() from the same function body.

Make 3 modules:

1. myfunc() as a template function
2. avx.d that imports myfunc() and instantiates it with avx backend settings.
3. sse.d that imports myfunc() and instantiates it with sse backend settings.