On 2/4/2012 2:04 PM, Era Scarecrow wrote:
[...]
struct X {
int i;
pure int squaredPlus(int x) {
return x*x + i
}
alias squaredPlus sqp;
}
X st(15);
writeln(st.sqp(0)); //15
int i1 = st.sqp(10); st.i++;
int i2 = st.sqp(10); st.i++;
int i3 =
On 2/4/2012 12:45 PM, Timon Gehr wrote:
[...]
Pure does not imply const in D.
[...]
I think this is a language defect:
struct Foo
{
int computed() pure { return x * y; }
int wrapper() const { return computed() + 5; }
int x;
int y;
}
void main()
{
}
src\Bug2.d(4): Error:
On Thu, Jan 02, 2014 at 04:31:24PM -0800, David Held wrote:
[...]
I think this is a language defect:
struct Foo
{
int computed() pure { return x * y; }
int wrapper() const { return computed() + 5; }
int x;
int y;
}
void main()
{
}
src\Bug2.d(4): Error: mutable
On 02/04/2012 08:51 PM, Era Scarecrow wrote:
If I'm reading how pure works, my original example was likely broken as
it was part of a struct that returned a state value (although the
contract constraints meaning was still valid).
So is pure fully usable or is it not yet ready? Makes me think
If I'm reading how pure works, my original example was likely
broken as it was part of a struct that returned a state value
(although the contract constraints meaning was still valid).
So is pure fully usable or is it not yet ready? Makes me think
that pure should have further
Pure does not imply const in D. If you want stronger
guarantees, just turn 'test' into a const (or immutable) member
function. In D, a function can change anything that is mutable
and reachable through its parameters, this includes the
implicit 'this' pointer. The reason for this design is
On 02/04/2012 11:04 PM, Era Scarecrow wrote:
Pure does not imply const in D. If you want stronger guarantees, just
turn 'test' into a const (or immutable) member function. In D, a
function can change anything that is mutable and reachable through its
parameters, this includes the implicit 'this'
Probably the restriction was lifted after TDPL was out.
Yes. The compiler will only reorder/run in parallel/optimize if
it is safe (not changing execution semantics). Pure can be used
to prove that certain optimizations are safe. If a pure
function only takes const or immutable arguments,
On 02/05/2012 12:15 AM, Era Scarecrow wrote:
Probably the restriction was lifted after TDPL was out.
Yes. The compiler will only reorder/run in parallel/optimize if it is
safe (not changing execution semantics). Pure can be used to prove
that certain optimizations are safe. If a pure
the signature I meant looks like
pure int squaredPlus(int)immutable;
Which then the only way you could call it, was if the object
itself was immutable, which is definitely safe (I think). Hmmm...
On 02/05/2012 01:20 AM, Era Scarecrow wrote:
the signature I meant looks like
pure int squaredPlus(int)immutable;
Which then the only way you could call it, was if the object itself was
immutable, which is definitely safe (I think). Hmmm...
Alternatively you can use pure int
On Sunday, 29 January 2012 at 06:22:26 UTC, Era Scarecrow wrote:
Maybe someone's brought this up, but i seem to have the
compiler complaining to me that my function isn't 'pure' by
calling a non-pure function, specifically to!string().
I don't see why this couldn't be done, not only does it
I don't see why this couldn't be done, not only does it get not
exist in release, it shouldn't be changing variables in
non-release. As mentioned there is a hole for debug code.
Report it:
http://d.puremagic.com/issues/
and we'll see what happens with that.
Reported; Minor priority (Won't
Maybe someone's brought this up, but i seem to have the compiler complaining
to me that my function isn't 'pure' by calling a non-pure function,
specifically to!string().
However the unpure functions are only accessed in the contracts, and only if
it failed seriously. Is this already planned
The way to avoid purity checking is to put code in a debug {} statement.
I'm not aware of any plans to disable purity checking for contracts.
15 matches
Mail list logo
