My guess is that Walter is concerned about cases like this:

struct S
{
    int *p;
   void foo() pure const
   {
      return  *p;
   }
}

static int w;

void blah()
{
    S s;
    s.p = &w;
    s.foo();
}

Although foo's only parameter is 'this', which is const, it still
reads from a global variable.
This means is that it's very difficult for a member function to be
strongly pure. In fact, we wouldn't lose much by assuming that member
functions are NEVER strongly pure.

*But*  this doesn't mean that they can't be weakly pure. If foo() is called from inside a strongly pure function, there is just no way that it can be impure, because there is no way that a global variable can be smuggled into it. The global would have to pass through the strongly pure function, and there is no way of doing that.


On 28 June 2011 13:49, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> I looked at the changes you made to phobos.? Let me examine one of them:
>
> struct Complex(T) if (isFloatingPoint!T)
> {
> ????/** The real part of the number. */
> ????T re;
>
> ????/** The imaginary part of the number. */
> ????T im;
>
>
> @safe nothrow /* removed attribute: pure */ // The following functions depend only on std.math. {
>
> ????/** Calculate the absolute value (or modulus) of the number. */
> ????@property T abs() const
> ????{
> ????????return hypot(re, im);
> ????}
> In fact, the abs function *is* pure (since hypot is pure).? Which is why I'm confused.? It does not modify any global or shared state.
>
> If the compiler no longer compiles this as pure, then it does *NOT* implement weak-pure semantics.? So I'm not sure what you mean by "I agree".? This is a step backwards.
>
> I'll examine it directly.? Complex!T.abs takes one parameter, a ref Complex!T.? Given the definition of weak-pure, a function is allowed to accept and access references to mutable data -- even change them -- as long as the data is not typed as shared.? It also does not call any impure functions or access any global variables.? I think you are completely wrong in thinking this cannot be pure.? If the compiler does not accept this, then the compiler has not implemented weak-pure.
>
> Do you have another case (even a theoretical one) that would have incorrectly compiled before this change?? Certainly the changes I looked at were not accepts-invalid cases, given the context that weak-pure was implemented.
>
> The other option is you simply don't want weak-pure.? Which is a design decision I don't agree with, but it's your decision.? It might be hard to get those worms back in the can now!
>
> -Steve
>
>
> ----- Original Message -----
>> From: Walter Bright <walter at digitalmars.com>
>> To: phobos at puremagic.com
>> Cc:
>> Sent: Monday, June 27, 2011 2:28 PM
>> Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not really pure
>>
>> I understand and agree, but the previous code was so broken it would allow assignment through the 'this' pointer.
>>
>> On 6/27/2011 3:51 AM, Steve Schveighoffer wrote:
>>> ?----- Original Message -----
>>>
>>>> ?From: Walter Bright<walter at digitalmars.com>
>>>>
>>>>
>>>>
>>>> ?On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>>>> ? ?On 2011-06-25 20:23, Walter Bright wrote:
>>>>>> ? ?On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>>>> ? ?If they're not really pure, they shouldn't
>> compile with
>>>> ?pure.
>>>>>> ? ?They won't in the upcoming checkin.
>>>>>>
>>>>>>> ? ? ? Also, not being
>>>>>>>
>>>>>>> ? ?able to use opAssign in pure functions could be rather
>> annoying.
>>>> ?Why
>>>>>>> ? ?doesn't that work?
>>>>>> ? ?Pure functions cannot mutate data through pointers passed to
>> them.
>>>>> ? ?Weakly pure functions are supposed to be able to.
>>>>>
>>>>>
>>>> ?The compiler wasn't checking this at all. It's possible we can
>> loosen
>>>> ?things up
>>>> ?after we understand the issues better, but we should start with being
>> very
>>>> ?conservative about what purity means.
>>> ?Don is probably the best to explain it, since he formalized the notion of
>> weak pure,? but I wholeheartedly agree with Jonathan, member functions that access or mutate mutable members can and should be pure, as long as they don't access or mutate shared or global data.
>>>
>>> ?If that isn't true, then the whole notion of weak purity that allows
>> pure functions to be useful is out the window.? I.e. pure functions will be reserved to the likes of std.math.sin, and nobody will mark any major functions pure.
>>>
>>> ?I thought weak purity had already been scrutinized, accepted, and
>> purposefully added to the compiler?? Were you not part of that discussion (I thought you were)?? Does this reverse that decision?? If so, I think it is the wrong move.? Weak purity made pure functions not only useful, but actually pleasant to work with.
>>>
>>> ?To recap weak purity, a pure function is one that does not access mutable
>> or const data that is shared or global, and it can only call pure functions.
>>> ?A Strong-pure function is a pure function whose parameters and return value
>> are all immutable or implicitly convertible to immutable.
>>>
>>> ?The compiler can only make pure-related optimizations on strong-pure
>> functions.? However, since weak-pure functions are still pure, strong-pure functions can call them.
>>>
>>> ?For instance, a useful idiom would be for a weak-pure function to sort an
>> array in place.? Without weak-purity, one has to re-implement sorting an array in every pure function they need it for, or write a functional-style sort (not a very easy or efficient thing).
>>>
>>> ?In other words, weak purity makes pure functions written in an imperative
>> style able to be modular.? Without it, you have to resort to functional style, or mixin everything into your local scope.
>>>
>>> ?-Steve
>>>
>>> ?_______________________________________________
>>> ?phobos mailing list
>>> ?phobos at puremagic.com
>>> ?http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

By definition, a strong-pure function must have all parameters immutable or implicitly convertible to immutable.? This function does not pass this test.

However, the function call *could* be considered strong pure if the S instance itself is immutable (at the call site).? Which means S s would have to be immutable, and the original assignment to &w does not compile.? It was you who brought up this idea in the first place, if you recall :)

This means whether a function that takes const parameters is weak-pure or strong-pure can depend on what values you call it with.

But, Walter's changes to phobos seems to imply that member functions cannot even be weak-pure.? I don't see any reason to disallow the member functions as weak-pure (and I think you are saying the same thing).? If this is Walter's case, I think it has no merit, but I'll reserve judgment until I know that this is in fact Walter's concern.

BTW, immutable member functions could definitely be strong-pure (depending on the other parameters).

-Steve



----- Original Message -----
> From: Don Clugston <dclugston at googlemail.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc:
> Sent: Tuesday, June 28, 2011 8:34 AM
> Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not really pure
> 
> My guess is that Walter is concerned about cases like this:
> 
> struct S
> {
> ? ? int *p;
> ?  void foo() pure const
> ?  {
> ? ? ? return? *p;
> ?  }
> }
> 
> static int w;
> 
> void blah()
> {
> ? ? S s;
> ? ? s.p = &w;
> ? ? s.foo();
> }
> 
> Although foo's only parameter is 'this', which is const, it still
> reads from a global variable.
> This means is that it's very difficult for a member function to be
> strongly pure. In fact, we wouldn't lose much by assuming that member
> functions are NEVER strongly pure.
> 
> *But*? this doesn't mean that they can't be weakly pure. If foo() is called from inside a strongly pure function, there is just no way that it can be impure, because there is no way that a global variable can be smuggled into it. The global would have to pass through the strongly pure function, and there is no way of doing that.
> 
> 
> On 28 June 2011 13:49, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>>  I looked at the changes you made to phobos.? Let me examine one of them:
>> 
>>  struct Complex(T) if (isFloatingPoint!T)
>>  {
>>  ????/** The real part of the number. */
>>  ????T re;
>> 
>>  ????/** The imaginary part of the number. */
>>  ????T im;
>> 
>> 
>>  @safe nothrow /* removed attribute: pure */ // The following functions
> depend only on std.math.
>>  {
>> 
>>  ????/** Calculate the absolute value (or modulus) of the number. */
>>  ????@property T abs() const
>>  ????{
>>  ????????return hypot(re, im);
>>  ????}
>>  In fact, the abs function *is* pure (since hypot is pure).? Which is why
> I'm confused.? It does not modify any global or shared state.
>> 
>>  If the compiler no longer compiles this as pure, then it does *NOT*
> implement weak-pure semantics.? So I'm not sure what you mean by "I agree".? This is a step backwards.
>> 
>>  I'll examine it directly.? Complex!T.abs takes one parameter, a ref
> Complex!T.? Given the definition of weak-pure, a function is allowed to accept and access references to mutable data -- even change them -- as long as the data is not typed as shared.? It also does not call any impure functions or access any global variables.? I think you are completely wrong in thinking this cannot be pure.? If the compiler does not accept this, then the compiler has not implemented weak-pure.
>> 
>>  Do you have another case (even a theoretical one) that would have
> incorrectly compiled before this change?? Certainly the changes I looked at were not accepts-invalid cases, given the context that weak-pure was implemented.
>> 
>>  The other option is you simply don't want weak-pure.? Which is a design
> decision I don't agree with, but it's your decision.? It might be hard to get those worms back in the can now!
>> 
>>  -Steve
>> 
>> 
>>  ----- Original Message -----
>>>  From: Walter Bright <walter at digitalmars.com>
>>>  To: phobos at puremagic.com
>>>  Cc:
>>>  Sent: Monday, June 27, 2011 2:28 PM
>>>  Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not
> really pure
>>> 
>>>  I understand and agree, but the previous code was so broken it would
> allow
>>>  assignment through the 'this' pointer.
>>> 
>>>  On 6/27/2011 3:51 AM, Steve Schveighoffer wrote:
>>>>  ?----- Original Message -----
>>>> 
>>>>>  ?From: Walter Bright<walter at digitalmars.com>
>>>>> 
>>>>> 
>>>>> 
>>>>>  ?On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>>>>>  ? ?On 2011-06-25 20:23, Walter Bright wrote:
>>>>>>>  ? ?On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>>>>>  ? ?If they're not really pure, they
> shouldn't
>>>  compile with
>>>>>  ?pure.
>>>>>>>  ? ?They won't in the upcoming checkin.
>>>>>>> 
>>>>>>>>  ? ? ? Also, not being
>>>>>>>> 
>>>>>>>>  ? ?able to use opAssign in pure functions could be
> rather
>>>  annoying.
>>>>>  ?Why
>>>>>>>>  ? ?doesn't that work?
>>>>>>>  ? ?Pure functions cannot mutate data through pointers
> passed to
>>>  them.
>>>>>>  ? ?Weakly pure functions are supposed to be able to.
>>>>>> 
>>>>>> 
>>>>>  ?The compiler wasn't checking this at all. It's
> possible we can
>>>  loosen
>>>>>  ?things up
>>>>>  ?after we understand the issues better, but we should start
> with being
>>>  very
>>>>>  ?conservative about what purity means.
>>>>  ?Don is probably the best to explain it, since he formalized the
> notion of
>>>  weak pure,? but I wholeheartedly agree with Jonathan, member functions
> that
>>>  access or mutate mutable members can and should be pure, as long as
> they
>>>  don't access or mutate shared or global data.
>>>> 
>>>>  ?If that isn't true, then the whole notion of weak purity that
> allows
>>>  pure functions to be useful is out the window.? I.e. pure functions
> will be
>>>  reserved to the likes of std.math.sin, and nobody will mark any major
> functions
>>>  pure.
>>>> 
>>>>  ?I thought weak purity had already been scrutinized, accepted, and
>>>  purposefully added to the compiler?? Were you not part of that
> discussion (I
>>>  thought you were)?? Does this reverse that decision?? If so, I think it
> is the
>>>  wrong move.? Weak purity made pure functions not only useful, but
> actually
>>>  pleasant to work with.
>>>> 
>>>>  ?To recap weak purity, a pure function is one that does not access
> mutable
>>>  or const data that is shared or global, and it can only call pure
> functions.
>>>>  ?A Strong-pure function is a pure function whose parameters and
> return value
>>>  are all immutable or implicitly convertible to immutable.
>>>> 
>>>>  ?The compiler can only make pure-related optimizations on
> strong-pure
>>>  functions.? However, since weak-pure functions are still pure,
> strong-pure
>>>  functions can call them.
>>>> 
>>>>  ?For instance, a useful idiom would be for a weak-pure function to
> sort an
>>>  array in place.? Without weak-purity, one has to re-implement sorting
> an array
>>>  in every pure function they need it for, or write a functional-style
> sort (not a
>>>  very easy or efficient thing).
>>>> 
>>>>  ?In other words, weak purity makes pure functions written in an
> imperative
>>>  style able to be modular.? Without it, you have to resort to functional
> style,
>>>  or mixin everything into your local scope.
>>>> 
>>>>  ?-Steve
>>>> 
>>>>  ?_______________________________________________
>>>>  ?phobos mailing list
>>>>  ?phobos at puremagic.com
>>>>  ?http://lists.puremagic.com/mailman/listinfo/phobos
>>>> 
>>>> 
>>>  _______________________________________________
>>>  phobos mailing list
>>>  phobos at puremagic.com
>>>  http://lists.puremagic.com/mailman/listinfo/phobos
>>> 
>>  _______________________________________________
>>  phobos mailing list
>>  phobos at puremagic.com
>>  http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On 28 June 2011 15:47, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> By definition, a strong-pure function must have all parameters immutable or implicitly convertible to immutable.? This function does not pass this test.
>
> However, the function call *could* be considered strong pure if the S instance itself is immutable (at the call site).? Which means S s would have to be immutable, and the original assignment to &w does not compile.? It was you who brought up this idea in the first place, if you recall :)

Yes, exactly.

> This means whether a function that takes const parameters is weak-pure or strong-pure can depend on what values you call it with.

Yes, though up to now it's only been very conservative: it is strong-pure only if all parameters are immutable.

> But, Walter's changes to phobos seems to imply that member functions cannot even be weak-pure.? I don't see any reason to disallow the member functions as weak-pure (and I think you are saying the same thing).? If this is Walter's case, I think it has no merit, but I'll reserve judgment until I know that this is in fact Walter's concern.

Now my guess to what's happened here is that the 'this' parameter had
escaped checks, so functions were erroneously being marked as strongly
pure.
But this shouldn't prevent them from being marked as weakly pure. But
I'm only guessing, maybe Walter has a different concern.

> BTW, immutable member functions could definitely be strong-pure (depending on the other parameters).

They could, but such cases are exceedingly rare and not very useful. I don't think they matter. It's weak purity that matters for member functions, since it allows them to be used in pure (static) functions.

- Don.


>> From: Don Clugston <dclugston at googlemail.com>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Cc:
>> Sent: Tuesday, June 28, 2011 8:34 AM
>> Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not really pure
>>
>> My guess is that Walter is concerned about cases like this:
>>
>> struct S
>> {
>> ? ? int *p;
>> ? ?void foo() pure const
>> ? ?{
>> ? ? ? return? *p;
>> ? ?}
>> }
>>
>> static int w;
>>
>> void blah()
>> {
>> ? ? S s;
>> ? ? s.p = &w;
>> ? ? s.foo();
>> }
>>
>> Although foo's only parameter is 'this', which is const, it still
>> reads from a global variable.
>> This means is that it's very difficult for a member function to be
>> strongly pure. In fact, we wouldn't lose much by assuming that member
>> functions are NEVER strongly pure.
>>
>> *But*? this doesn't mean that they can't be weakly pure. If foo() is called from inside a strongly pure function, there is just no way that it can be impure, because there is no way that a global variable can be smuggled into it. The global would have to pass through the strongly pure function, and there is no way of doing that.
>>
>>
>> On 28 June 2011 13:49, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>>> ?I looked at the changes you made to phobos.? Let me examine one of them:
>>>
>>> ?struct Complex(T) if (isFloatingPoint!T)
>>> ?{
>>> ?????/** The real part of the number. */
>>> ?????T re;
>>>
>>> ?????/** The imaginary part of the number. */
>>> ?????T im;
>>>
>>>
>>> ?@safe nothrow /* removed attribute: pure */ // The following functions
>> depend only on std.math.
>>> ?{
>>>
>>> ?????/** Calculate the absolute value (or modulus) of the number. */
>>> ?????@property T abs() const
>>> ?????{
>>> ?????????return hypot(re, im);
>>> ?????}
>>> ?In fact, the abs function *is* pure (since hypot is pure).? Which is why
>> I'm confused.? It does not modify any global or shared state.
>>>
>>> ?If the compiler no longer compiles this as pure, then it does *NOT*
>> implement weak-pure semantics.? So I'm not sure what you mean by "I agree".? This is a step backwards.
>>>
>>> ?I'll examine it directly.? Complex!T.abs takes one parameter, a ref
>> Complex!T.? Given the definition of weak-pure, a function is allowed to accept and access references to mutable data -- even change them -- as long as the data is not typed as shared.? It also does not call any impure functions or access any global variables.? I think you are completely wrong in thinking this cannot be pure.? If the compiler does not accept this, then the compiler has not implemented weak-pure.
>>>
>>> ?Do you have another case (even a theoretical one) that would have
>> incorrectly compiled before this change?? Certainly the changes I looked at were not accepts-invalid cases, given the context that weak-pure was implemented.
>>>
>>> ?The other option is you simply don't want weak-pure.? Which is a design
>> decision I don't agree with, but it's your decision.? It might be hard to get those worms back in the can now!
>>>
>>> ?-Steve
>>>
>>>
>>> ?----- Original Message -----
>>>> ?From: Walter Bright <walter at digitalmars.com>
>>>> ?To: phobos at puremagic.com
>>>> ?Cc:
>>>> ?Sent: Monday, June 27, 2011 2:28 PM
>>>> ?Subject: Re: [phobos] [D-Programming-Language/phobos] 4f28db: not
>> really pure
>>>>
>>>> ?I understand and agree, but the previous code was so broken it would
>> allow
>>>> ?assignment through the 'this' pointer.
>>>>
>>>> ?On 6/27/2011 3:51 AM, Steve Schveighoffer wrote:
>>>>> ??----- Original Message -----
>>>>>
>>>>>> ??From: Walter Bright<walter at digitalmars.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ??On 6/25/2011 8:25 PM, Jonathan M Davis wrote:
>>>>>>> ?? ?On 2011-06-25 20:23, Walter Bright wrote:
>>>>>>>> ?? ?On 6/25/2011 8:01 PM, Jonathan M Davis wrote:
>>>>>>>>> ?? ?If they're not really pure, they
>> shouldn't
>>>> ?compile with
>>>>>> ??pure.
>>>>>>>> ?? ?They won't in the upcoming checkin.
>>>>>>>>
>>>>>>>>> ?? ? ? Also, not being
>>>>>>>>>
>>>>>>>>> ?? ?able to use opAssign in pure functions could be
>> rather
>>>> ?annoying.
>>>>>> ??Why
>>>>>>>>> ?? ?doesn't that work?
>>>>>>>> ?? ?Pure functions cannot mutate data through pointers
>> passed to
>>>> ?them.
>>>>>>> ?? ?Weakly pure functions are supposed to be able to.
>>>>>>>
>>>>>>>
>>>>>> ??The compiler wasn't checking this at all. It's
>> possible we can
>>>> ?loosen
>>>>>> ??things up
>>>>>> ??after we understand the issues better, but we should start
>> with being
>>>> ?very
>>>>>> ??conservative about what purity means.
>>>>> ??Don is probably the best to explain it, since he formalized the
>> notion of
>>>> ?weak pure,? but I wholeheartedly agree with Jonathan, member functions
>> that
>>>> ?access or mutate mutable members can and should be pure, as long as
>> they
>>>> ?don't access or mutate shared or global data.
>>>>>
>>>>> ??If that isn't true, then the whole notion of weak purity that
>> allows
>>>> ?pure functions to be useful is out the window.? I.e. pure functions
>> will be
>>>> ?reserved to the likes of std.math.sin, and nobody will mark any major
>> functions
>>>> ?pure.
>>>>>
>>>>> ??I thought weak purity had already been scrutinized, accepted, and
>>>> ?purposefully added to the compiler?? Were you not part of that
>> discussion (I
>>>> ?thought you were)?? Does this reverse that decision?? If so, I think it
>> is the
>>>> ?wrong move.? Weak purity made pure functions not only useful, but
>> actually
>>>> ?pleasant to work with.
>>>>>
>>>>> ??To recap weak purity, a pure function is one that does not access
>> mutable
>>>> ?or const data that is shared or global, and it can only call pure
>> functions.
>>>>> ??A Strong-pure function is a pure function whose parameters and
>> return value
>>>> ?are all immutable or implicitly convertible to immutable.
>>>>>
>>>>> ??The compiler can only make pure-related optimizations on
>> strong-pure
>>>> ?functions.? However, since weak-pure functions are still pure,
>> strong-pure
>>>> ?functions can call them.
>>>>>
>>>>> ??For instance, a useful idiom would be for a weak-pure function to
>> sort an
>>>> ?array in place.? Without weak-purity, one has to re-implement sorting
>> an array
>>>> ?in every pure function they need it for, or write a functional-style
>> sort (not a
>>>> ?very easy or efficient thing).
>>>>>
>>>>> ??In other words, weak purity makes pure functions written in an
>> imperative
>>>> ?style able to be modular.? Without it, you have to resort to functional
>> style,
>>>> ?or mixin everything into your local scope.
>>>>>
>>>>> ??-Steve
>>>>>
>>>>> ??_______________________________________________
>>>>> ??phobos mailing list
>>>>> ??phobos at puremagic.com
>>>>> ??http://lists.puremagic.com/mailman/listinfo/phobos
>>>>>
>>>>>
>>>> ?_______________________________________________
>>>> ?phobos mailing list
>>>> ?phobos at puremagic.com
>>>> ?http://lists.puremagic.com/mailman/listinfo/phobos
>>>>
>>> ?_______________________________________________
>>> ?phobos mailing list
>>> ?phobos at puremagic.com
>>> ?http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On 2011-06-28 08:22, Don Clugston wrote:
> On 28 June 2011 15:47, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> > By definition, a strong-pure function must have all parameters immutable or implicitly convertible to immutable.  This function does not pass this test.
> > 
> > However, the function call *could* be considered strong pure if the S instance itself is immutable (at the call site).  Which means S s would have to be immutable, and the original assignment to &w does not compile.  It was you who brought up this idea in the first place, if you recall :)
> 
> Yes, exactly.
> 
> > This means whether a function that takes const parameters is weak-pure or strong-pure can depend on what values you call it with.
> 
> Yes, though up to now it's only been very conservative: it is strong-pure only if all parameters are immutable.
> 
> > But, Walter's changes to phobos seems to imply that member functions cannot even be weak-pure.  I don't see any reason to disallow the member functions as weak-pure (and I think you are saying the same thing).  If this is Walter's case, I think it has no merit, but I'll reserve judgment until I know that this is in fact Walter's concern.
> 
> Now my guess to what's happened here is that the 'this' parameter had
> escaped checks, so functions were erroneously being marked as strongly
> pure.
> But this shouldn't prevent them from being marked as weakly pure. But
> I'm only guessing, maybe Walter has a different concern.
> 
> > BTW, immutable member functions could definitely be strong-pure
> > (depending on the other parameters).
> 
> They could, but such cases are exceedingly rare and not very useful. I don't think they matter. It's weak purity that matters for member functions, since it allows them to be used in pure (static) functions.

Ideally, under at least some circumstances, const member functions would be considered strongly pure given that it's known that the object that they're called on isn't altered within the expression. I don't know how well that that would actually work though. Certainly, the rules on weak purity would have to be relaxed a bit based on how the functions are called (which Steve was talking about), so I wouldn't expect it to be happening at this point regardless. But ideally it would.

- Jonathan M Davis

On Tue, 28 Jun 2011 21:39:49 +0200, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> Ideally, under at least some circumstances, const member functions would
> be
> considered strongly pure given that it's known that the object that
> they're
> called on isn't altered within the expression. I don't know how well
> that that
> would actually work though. Certainly, the rules on weak purity would
> have to
> be relaxed a bit based on how the functions are called (which Steve was
> talking about), so I wouldn't expect it to be happening at this point
> regardless. But ideally it would.

I don't believe they could, no. Some other thread might change the object while it's inside the member function.

-- 
   Simen

On 2011-06-28 15:02, Simen Kjaeraas wrote:
> On Tue, 28 Jun 2011 21:39:49 +0200, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > Ideally, under at least some circumstances, const member functions would
> > be
> > considered strongly pure given that it's known that the object that
> > they're
> > called on isn't altered within the expression. I don't know how well
> > that that
> > would actually work though. Certainly, the rules on weak purity would
> > have to
> > be relaxed a bit based on how the functions are called (which Steve was
> > talking about), so I wouldn't expect it to be happening at this point
> > regardless. But ideally it would.
> 
> I don't believe they could, no. Some other thread might change the object while it's inside the member function.

Except that they're thread-local if not shared, aren't they?

- Jonathan M Davis

Could somebody revert this please? (and the similar druntime change)
Weakly pure functions should be able to do anything they like with
data reachable through their parameters, including the 'this'
parameter, as of the new purity rules.
I can't build druntime from head and it seems to be caused by this.

If the rules need to me discussed some more or changed, dmd+druntime+phobos should at least be compiling while that happens.

I'm fairly sure druntime and phobos are both broken by these changes, it's just not showing up on the autotester because the dmd tests are failing as well.

My mistake, this commit is not the one breaking phobos for me. (Just
the druntime change)  (I still think it should be reverted)

On Wed, Jun 29, 2011 at 9:04 PM, Daniel Murphy <yebblies at gmail.com> wrote:
> Could somebody revert this please? (and the similar druntime change)
> Weakly pure functions should be able to do anything they like with
> data reachable through their parameters, including the 'this'
> parameter, as of the new purity rules.
> I can't build druntime from head and it seems to be caused by this.
>
> If the rules need to me discussed some more or changed, dmd+druntime+phobos should at least be compiling while that happens.
>
> I'm fairly sure druntime and phobos are both broken by these changes, it's just not showing up on the autotester because the dmd tests are failing as well.
>