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. Useful
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 t
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 thi
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 fun
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 fun
particularly with
larger 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
t as "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
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)!
>
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 w
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 wr
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 question,
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 combinatio
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 followi
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 followi
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 Lin
ction 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
no mutable, 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.
F
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 ?
Most
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. Yo
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 ?
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=1
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"
/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();
}
vo
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
c
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:
-
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() {
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() p
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 s
x27; some existing code I 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
x27;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 {
s 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 roundTo!int(d);
}
"""
Thanks for any pointers!
-Chris
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 currentl
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 Wednesday, March 07, 2012 17:29:24 Simen Kjærås wrote:
> On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis
>
> wrote:
> > It really takes very little for something to be impure, and optimizations
> > often do it, because they end up using low-level constructs
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
> >
> > wrote:
> >> It really takes very little for something to be impure, and optimizations
> >>
On 03/07/2012 05:29 PM, Simen Kjærås wrote:
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis
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 a
On Wed, 07 Mar 2012 01:41:22 +0100, Jonathan M Davis
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 probabl
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 al
7;t marked as pure,
since it's a C function. It theoretically _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 w
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);
>
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 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 want
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 e
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.
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 eith
() {}
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'
>
> I think I asked a similar question in past, is it right to expect DMD to
> compile this program?
If foo is CTFE-able, yes.
: 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
52 matches
Mail list logo
