http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

1. updated rdmd
2. 64 bit dmd binary on Linux
3. CTFE added to D1 changelog
4. fixed missing update to phobos sources

Again, where does this leave the weakly pure function issue?  I want to be sure that weak purity for non-const member functions is going away forever before I take it out of all my code and test this beta in any detail.

On Wed, Jul 6, 2011 at 2:55 PM, Walter Bright <walter at digitalmars.com>wrote:

>
> http://ftp.digitalmars.com/**dmd1beta.zip<http://ftp.digitalmars.com/dmd1beta.zip> http://ftp.digitalmars.com/**dmd2beta.zip<http://ftp.digitalmars.com/dmd2beta.zip>
>
> 1. updated rdmd
> 2. 64 bit dmd binary on Linux
> 3. CTFE added to D1 changelog
> 4. fixed missing update to phobos sources
> ______________________________**_________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-beta<http://lists.puremagic.com/mailman/listinfo/dmd-beta>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110706/19adbfd2/attachment.html>

On 6 jul 2011, at 20:55, Walter Bright wrote:

> 
> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
> 
> 1. updated rdmd
> 2. 64 bit dmd binary on Linux
> 3. CTFE added to D1 changelog
> 4. fixed missing update to phobos sources
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta


RDMD for Mac OS X and FreeBSD is still missing from the DMD1 zip. The FreeBSD executables in the DMD2 zip doesn't have executable permission.

-- 
/Jacob Carlborg

Does RDMD even support BSDs? I guess this falls under Posix in the version statement?

On 7/6/2011 12:08 PM, David Simcha wrote:
> Again, where does this leave the weakly pure function issue?  I want to be sure that weak purity for non-const member functions is going away forever before I take it out of all my code and test this beta in any detail.
>

The trouble was that there were a lot of functions marked as 'pure' that were changing things pointed to by its arguments.

I understand that within a pure function, such a pure function could modify locals without the caller becoming impure. But those functions are still impure.

I've noticed that properties returning ref (const) are now matched when assigning a value:

---
struct S {
     private int m_prop;
     ref const(int) prop() { return m_prop; }
     void prop(int v) { m_prop = v; }
}

void test()
{
     S s;
     s.prop = 1;
}
---

causes the error "bug.d(10): Error: s.prop is not mutable". Declaring the setter first will fix this, which I would consider another bug (property resolution should probably not be order dependent), but that bug has existed in previous versions.

Added http://d.puremagic.com/issues/show_bug.cgi?id=6259


Am 06.07.2011 20:55, schrieb Walter Bright:
>
> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>
> 1. updated rdmd
> 2. 64 bit dmd binary on Linux
> 3. CTFE added to D1 changelog
> 4. fixed missing update to phobos sources
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 2011-07-06 12:46, Walter Bright wrote:
> On 7/6/2011 12:08 PM, David Simcha wrote:
> > Again, where does this leave the weakly pure function issue?  I want to be sure that weak purity for non-const member functions is going away forever before I take it out of all my code and test this beta in any detail.
> 
> The trouble was that there were a lot of functions marked as 'pure' that were changing things pointed to by its arguments.
> 
> I understand that within a pure function, such a pure function could modify locals without the caller becoming impure. But those functions are still impure.

But they're supposed to be weakly pure, because they don't alter an global or static variables. They're _supposed_ to be able to alter stuff which is passed to them. They're just weakly pure instead of strongly pure and thus can't be optimized out. Then strongly pure functions can call them and retain all of their guarantees. It sounds like you're throwing out the whole idea of weak purity. Certainly, as it stands, weak purity is pretty thoroughly trashed if not outright gone.

- Jonathan M Davis

On 7/6/2011 12:09 PM, Jacob Carlborg wrote:
>
> RDMD for Mac OS X and FreeBSD is still missing from the DMD1 zip.

I'm a little unsure about this as rdmd has not been tested with D1.

>   The FreeBSD executables in the DMD2 zip doesn't have executable permission.
>

Done.

On 7/6/11 9:46 PM, Walter Bright wrote:
> I understand that within a pure function, such a pure function could modify locals without the caller becoming impure. But those functions are still impure.

Isn't this the whole idea behind weak purity, which we introduced in 2.050? Weakly pure functions are supposed to be able to modify their arguments, yet are still tagged with the ?pure? attribute and thus callable from (possibly strongly) pure functions.

Whether the implicit this parameter is part of the arguments through which external state can be read/modified is a separate another question (though I would argue in favor of it, since otherwise objects resp. member functions become unnecessarily crippled inside pure functions), but right now it seems like you are throwing the whole concept of ?weak purity?, i.e. the ?relaxed? purity rules out of the window. Or did I get you wrong?

David

This is exactly what I was trying to get at, though David Nadlinger stated it better than I did:  Are we abandoning weak purity?  If so, why?  If not, please clarify the new rules and explain why the newly disallowed behavior doesn't fit into the framework of weak purity.

On Wed, Jul 6, 2011 at 3:57 PM, David Nadlinger <code at klickverbot.at> wrote:

> On 7/6/11 9:46 PM, Walter Bright wrote:
>
>> I understand that within a pure function, such a pure function could modify locals without the caller becoming impure. But those functions are still impure.
>>
>
> Isn't this the whole idea behind weak purity, which we introduced in 2.050? Weakly pure functions are supposed to be able to modify their arguments, yet are still tagged with the ?pure? attribute and thus callable from (possibly strongly) pure functions.
>
> Whether the implicit this parameter is part of the arguments through which external state can be read/modified is a separate another question (though I would argue in favor of it, since otherwise objects resp. member functions become unnecessarily crippled inside pure functions), but right now it seems like you are throwing the whole concept of ?weak purity?, i.e. the ?relaxed? purity rules out of the window. Or did I get you wrong?
>
> David
>
> ______________________________**_________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-beta<http://lists.puremagic.com/mailman/listinfo/dmd-beta>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110706/30872042/attachment.html>