On Monday, 8 April 2024 at 07:53:01 UTC, Dom DiSc wrote:
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
Try `debug unittest {...}`?
Cool. This seems to work. That's a nice workaroud for tests.
Yay!
Nice, fyi, you can use it with statements inside function bodies
as well.
On Monday, 8 April 2024 at 07:03:40 UTC, Alexandru Ermicioi wrote:
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only
On Sunday, 7 April 2024 at 23:32:24 UTC, MrJay wrote:
A better way to apply a attribute to an entire file is to use
an explicit scope you can still apply this to basically the
entire file but leave the tests out of it.
Better than an explicit impure (or pure=false) attribute?
I don't think so
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only probabilistic)!
So do I really need to declare every function pure
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only probabilistic)!
So do I really need to declare every function pure
rger projects.
> If the addition of new keywords (like "throws", "@gc" and
> "impure") is a problem, why not doing it like @nogc(false) or
> @nogc=false (likewise for nothrow and pure)?
There are a number of ways that it could be done, but regardless, we'd nee
;mass-applying attributes" rather than changing
the default to something more sane, so that I have to apply
*less* attributes to any single function.
If the addition of new keywords (like "throws", "@gc" and
"impure") is a problem, why not doing it lik
On Sunday, March 24, 2024 1:41:41 AM MDT Dom DiSc via Digitalmars-d-learn
wrote:
> I'm creating a library that is completely pure, but it doesn't
> compile with pure: at the top because of one impure unittest
> (which uses random to test some things only probabilistic)!
>
> So d
On Sunday, 4 October 2020 at 18:02:11 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:43:13 UTC, Michael wrote:
[...]
I used the dmg file: dmd.2.094.0.dmg
I reinstalled using the installation script (install.sh) and
now it works. Still don't know why the dmg-based intstallation
did not
On Sunday, 4 October 2020 at 17:43:13 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:37:52 UTC, Mathias LANG wrote:
On Sunday, 4 October 2020 at 17:05:33 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael
On Sunday, 4 October 2020 at 17:37:52 UTC, Mathias LANG wrote:
On Sunday, 4 October 2020 at 17:05:33 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the following trivial code fail?
[...]
I have tried my best to make it fail, but can't. Maybe it's
something with the
On Sunday, 4 October 2020 at 17:05:33 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the
On Sunday, 4 October 2020 at 17:05:33 UTC, Michael wrote:
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the
On Sunday, 4 October 2020 at 17:01:44 UTC, Paul Backus wrote:
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the following trivial code
fail?
import std.stdio;
void main()
{
On Sunday, 4 October 2020 at 16:48:24 UTC, Michael wrote:
Dear all,
Sorry for the potentially stupid question, but I'm a complete
newbie to D. Why does compiling the following trivial code fail?
import std.stdio;
void main()
{
writeln(3.14);
}
Works fine for me using DMD 2.094.0 on
std.format.FormatSpec!char.FormatSpec.toString cannot
call impure function
std.format.FormatSpec!char.FormatSpec.toString!(Appender!string).toString
/Library/D/dmd/src/phobos/std/format.d(478): Error: template
instance std.format.FormatSpec!char error instantiating
/Library/D/dmd/src/phobos/std/stdio.d(1590
, impure, @gc and throws.
Why is that ?
Mostly because nobody's bothered to add them (yet). There's an
accepted proposal to add a "throw" attribute as the opposite of
nothrow [1], but it looks like it still hasn't been implemented
in the compiler.
For const and immutable, y
On Monday, 7 September 2020 at 11:25:15 UTC, wjoe wrote:
It's easy to declare the entire module @safe and functions
which can't be can be declared @system.
However there is const, immutable, pure, @nogc and nothrow but
no mutable, impure, @gc and throws.
Why is that ?
Mostly because
It's easy to declare the entire module @safe and functions which
can't be can be declared @system.
However there is const, immutable, pure, @nogc and nothrow but no
mutable, impure, @gc and throws.
Why is that ?
On Tuesday, 13 December 2016 at 05:13:01 UTC, Nikhil Jacob wrote:
I mistook the original statement to mean that an impure
function can be called from a pure function with some manual
overrides.
Thank you for the clarification.
Yeah you can't do that, except in a debug statement. You can
On Tuesday, 13 December 2016 at 04:48:11 UTC, Nikhil Jacob wrote:
In the D spec for pure functions it says that a pure function
can override
"can override an impure function, but an impure function cannot
override a pure one"
Can anyone help me how to do this ?
what this means
On Tuesday, 13 December 2016 at 05:10:02 UTC, Nicholas Wilson
wrote:
On Tuesday, 13 December 2016 at 04:48:11 UTC, Nikhil Jacob
wrote:
In the D spec for pure functions it says that a pure function
can override
"can override an impure function, but an impure function
cannot override a
In the D spec for pure functions it says that a pure function can
override
"can override an impure function, but an impure function cannot
override a pure one"
Can anyone help me how to do this ?
at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot
call impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln(DTor);
}
}
A getA() pure
In this case, the created struct literal A() will be moved out
to the function getA(). So dtor is not called and compiler
should not cause cannot call impure function error.
I filed a bug report and posted possible compiler fix.
http://d.puremagic.com/issues/show_bug.cgi?id=11286
https
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot call
impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln(DTor
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot call
impure function 'f223.A.~this'
with this code:
import std.stdio
On Wednesday, 16 October 2013 at 07:27:25 UTC, Namespace wrote:
On Wednesday, 16 October 2013 at 07:23:45 UTC, monarch_dodra
wrote:
On Tuesday, 15 October 2013 at 21:37:40 UTC, Namespace wrote:
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot
call impure
/f223.d(11): Error: pure function 'f223.getA' cannot
call impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln(DTor);
}
}
A getA() pure nothrow {
return A();
}
void main()
{
A a = getA
I get this error:
/d701/f223.d(11): Error: pure function 'f223.getA' cannot call
impure function 'f223.A.~this'
with this code:
import std.stdio;
struct A {
public:
~this() {
writeln(DTor);
}
}
A getA() pure nothrow {
return A();
}
void
floating-point library calls? (e.g. I
noticed std.math.floor() is impure as well).
import std.conv;
int func(double d) pure { // compiles...
return to!int(d);
}
int func2(double d) pure { //doesn't compile!?!
return roundTo!int(d);
}
Thanks for any pointers!
-Chris
understand why. Is this a
general problem with most floating-point library calls? (e.g. I
noticed std.math.floor() is impure as well).
import std.conv;
int func(double d) pure { // compiles...
return to!int(d);
}
int func2(double d) pure { //doesn't compile!?!
return
discovered that I can't use
roundTo in a pure function, and I don't understand why. Is
this a
general problem with most floating-point library calls? (e.g. I
noticed std.math.floor() is impure as well).
import std.conv;
int func(double d) pure { // compiles...
return to!int(d);
}
int
On Sunday, June 10, 2012 04:06:03 Chris Saunders wrote:
Thanks Jonathan. Sounds like a practical issue rather than some
theoretical problem -- good to know.
The vast majority of purity issues with Phobos are purely an implementation
issue and not any kind of limit in the language. Obviously
On 23/05/12 11:41, bearophile wrote:
Simen Kjaeraas:
Should this be filed as a bug, or is the plan that only pure functions be
ctfe-able? (or has someone already filed it, perhaps)
It's already in Bugzilla, see issue 7994 and 6169.
It's just happening because the purity checking is
Simen Kjaeraas:
Should this be filed as a bug, or is the plan that only pure
functions be
ctfe-able? (or has someone already filed it, perhaps)
It's already in Bugzilla, see issue 7994 and 6169.
But I think there is a semantic hole in some of the discussions
about this problem. Is a future
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
It really takes very little for something to be impure, and optimizations
often do it, because they end up using low-level constructs which aren't
pure
- some of which could be but aren't and others which
On 03/07/2012 05:29 PM, Simen Kjærås wrote:
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
It really takes very little for something to be impure, and optimizations
often do it, because they end up using low-level constructs which
aren't pure
- some of which
On Wednesday, March 07, 2012 17:58:43 Timon Gehr wrote:
On 03/07/2012 05:29 PM, Simen Kjærås wrote:
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis
jmdavisp...@gmx.com wrote:
It really takes very little for something to be impure, and optimizations
often do it, because they end up
On Wednesday, March 07, 2012 17:29:24 Simen Kjærås wrote:
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
It really takes very little for something to be impure, and optimizations
often do it, because they end up using low-level constructs which aren't
Why is std.algorithm.reduce not marked pure? It makes it impossible to
do things like this:
pure const int product(int[] args) {
return reduce!a * b(args);
}
T
--
Life is unfair. Ask too much from it, and it may decide you don't deserve what
you have now
On Tuesday, 6 March 2012 at 22:39:20 UTC, H. S. Teoh wrote:
Why is std.algorithm.reduce not marked pure?
It doesn't have to be - templates are inferred to be
pure or not.
If you take the const off that signature, your example
works in today's dmd.
On Tue, Mar 06, 2012 at 11:42:00PM +0100, Adam D. Ruppe wrote:
On Tuesday, 6 March 2012 at 22:39:20 UTC, H. S. Teoh wrote:
Why is std.algorithm.reduce not marked pure?
It doesn't have to be - templates are inferred to be
pure or not.
If you take the const off that signature, your example
On Tuesday, 6 March 2012 at 22:48:30 UTC, H. S. Teoh wrote:
Oh? what's wrong with the const?
test10.d(3): Error: function test10.product without 'this' cannot
be const/immutable
It works if you put parens on it:
pure const(int) product(int[] args) {
Without the parenthesis, D
On Tue, Mar 06, 2012 at 11:51:05PM +0100, Adam D. Ruppe wrote:
On Tuesday, 6 March 2012 at 22:48:30 UTC, H. S. Teoh wrote:
Oh? what's wrong with the const?
test10.d(3): Error: function test10.product without 'this' cannot be
const/immutable
It works if you put parens on it:
On Tue, Mar 06, 2012 at 03:00:16PM -0800, H. S. Teoh wrote:
[...]
But why can't 'this' be const? For example, why does the compiler
reject this:
class A {
int[] data;
pure const int sum() {
return reduce!a*b(data);
}
_could_ be marked as pure - and
arguably should be - but I very much doubt that it is right now.
It really takes very little for something to be impure, and optimizations
often do it, because they end up using low-level constructs which aren't pure
- some of which could be but aren't and others
H. S. Teoh:
But why can't 'this' be const? For example, why does the compiler reject
this:
class A {
int[] data;
pure const int sum() {
return reduce!a*b(data);
}
}
I'm not modifying data at at all, so why
: pure function 'bar' cannot call impure function 'foo'
test.d(5):called from here: foo()
test.d(5):called from here: foo()
test.d(6): Error: pure function 'bar' cannot call impure function 'foo'
test.d(6):called from here: foo()
test.d(6):called from here: foo()
I
() {}
The latest DMD gives:
test.d(5): Error: pure function 'bar' cannot call impure function 'foo'
test.d(5):called from here: foo()
test.d(5):called from here: foo()
test.d(6): Error: pure function 'bar' cannot call impure function 'foo'
test.d(6):called from here: foo
51 matches
Mail list logo
