Simen Kjaeraas wrote:
On Mon, 22 Aug 2011 22:19:50 +0200, Don wrote:
BTW: The whole "weak pure"/"strong pure" naming was just something I
came up with, to convince Walter to relax the purity rules. I'd rather
those names disappeared, they aren't very helpful.
The concepts are useful, but be
On Monday, August 22, 2011 15:57 Timon Gehr wrote:
> On 08/22/2011 10:19 PM, Don wrote:
> > Timon Gehr wrote:
> >> On 08/21/2011 09:10 PM, Don wrote:
> >>> bearophile wrote:
> Sean Eskapp:
> > Oh, I see, thanks! This isn't documented in the function
> > documentation!
>
> D
On 08/22/2011 10:19 PM, Don wrote:
Timon Gehr wrote:
On 08/21/2011 09:10 PM, Don wrote:
bearophile wrote:
Sean Eskapp:
Oh, I see, thanks! This isn't documented in the function
documentation!
D purity implementation looks like a simple thing, but it's not
simple, it has several parts that i
On Mon, 22 Aug 2011 22:19:50 +0200, Don wrote:
BTW: The whole "weak pure"/"strong pure" naming was just something I
came up with, to convince Walter to relax the purity rules. I'd rather
those names disappeared, they aren't very helpful.
The concepts are useful, but better names might be w
Timon Gehr wrote:
On 08/21/2011 09:10 PM, Don wrote:
bearophile wrote:
Sean Eskapp:
Oh, I see, thanks! This isn't documented in the function documentation!
D purity implementation looks like a simple thing, but it's not
simple, it has several parts that in the last months have be added to
t
On Sat, 20 Aug 2011 12:43:29 -0400, Timon Gehr wrote:
On 08/20/2011 06:24 PM, Sean Eskapp wrote:
== Quote from David Nadlinger (s...@klickverbot.at)'s article
On 8/20/11 5:13 PM, Sean Eskapp wrote:
Does marking a member function as pure mean that it will return the
same
result given the sam
On 08/21/2011 09:10 PM, Don wrote:
bearophile wrote:
Sean Eskapp:
Oh, I see, thanks! This isn't documented in the function documentation!
D purity implementation looks like a simple thing, but it's not
simple, it has several parts that in the last months have be added to
the language and com
bearophile wrote:
Sean Eskapp:
Oh, I see, thanks! This isn't documented in the function documentation!
D purity implementation looks like a simple thing, but it's not simple, it has
several parts that in the last months have be added to the language and
compiler, and we are not done yet, th
implementation of functions with stronger purity guarantees.
> > const pure/strongly pure:
> > All function arguments are values or const/immutable.
> >
> > From the type signature of a function, you can always tell which form
> >
> > of pure function it is:
&
Sean Eskapp:
> Oh, I see, thanks! This isn't documented in the function documentation!
D purity implementation looks like a simple thing, but it's not simple, it has
several parts that in the last months have be added to the language and
compiler, and we are not done yet, there are few more thi
always tell which form
> of pure function it is:
> int foo(ref int, int) pure; // weakly pure, could change first argument
> int bar(const(int)*, int) pure; // const pure
> int qux(immutable(int)*, int) pure; // strongly pure
> Weakly pure member functions can therefore change the
table.
From the type signature of a function, you can always tell which form
of pure function it is:
int foo(ref int, int) pure; // weakly pure, could change first argument
int bar(const(int)*, int) pure; // const pure
int qux(immutable(int)*, int) pure; // strongly pure
Weakly pure member function
== Quote from David Nadlinger (s...@klickverbot.at)'s article
> On 8/20/11 5:13 PM, Sean Eskapp wrote:
> > Does marking a member function as pure mean that it will return the same
> > result given the same parameters, or that it will give the same result,
> > given
> > the same parameters and give
On 8/20/11 5:13 PM, Sean Eskapp wrote:
Does marking a member function as pure mean that it will return the same
result given the same parameters, or that it will give the same result, given
the same parameters and given the same class/struct members?
The second one, the implicit this parameter
Does marking a member function as pure mean that it will return the same
result given the same parameters, or that it will give the same result, given
the same parameters and given the same class/struct members?
On Mon, 20 Sep 2010 16:26:44 -0400, Don wrote:
Steven Schveighoffer wrote:
I think it's ok for a function to be pure if all the arguments are
unshared, regardless of immutability. However, in order to cache the
return value, the reference itself must not be used as the key, but the
enti
Steven Schveighoffer wrote:
On Mon, 20 Sep 2010 15:45:10 -0400, Don wrote:
bearophile wrote:
Jonathan M Davis:
I assume that if you declare a member function as pure, then all of
its parameters - including the invisible this - are included in
that. That is, if all of them - including the i
On Mon, 20 Sep 2010 15:45:10 -0400, Don wrote:
bearophile wrote:
Jonathan M Davis:
I assume that if you declare a member function as pure, then all of
its parameters - including the invisible this - are included in that.
That is, if all of them - including the invisible this - have the sa
bearophile wrote:
Jonathan M Davis:
I assume that if you declare a member function as pure, then all of its
parameters - including the invisible this - are included in that. That is, if
all of them - including the invisible this - have the same value, then the
result will be the same.
This
Jonathan M Davis:
> I assume that if you declare a member function as pure, then all of its
> parameters - including the invisible this - are included in that. That is, if
> all of them - including the invisible this - have the same value, then the
> result will be the same.
This D2 program ru
I assume that if you declare a member function as pure, then all of its
parameters - including the invisible this - are included in that. That is, if
all of them - including the invisible this - have the same value, then the
result will be the same.
I'm not quite sure way (perhaps because pure
21 matches
Mail list logo
