It's now been two months since the last release, and there have been
huge compiler improvements.
Note also that there were a couple of very bad regressions in 2.052,
so I think we really need a release ASAP.
We've now achieved minimal stability again (all green on the auto-tester).

Here's the things which are blockers for the next release:

>From the compiler side:
* struct destruction of temporaries (seems like we have a chance of
fixing this soon)
* fixing the regressions from my CTFE/const folding changes (Fixes are
here: https://github.com/D-Programming-Language/dmd/pull/37).
* a few things haven't been backported to D1 yet
druntime:
* clean up Windows DLL support
phobos:
* nothing that I know of

Looks as though will be time to get std.parallelism in. But otherwise, if you have anything you'd like to get into the next release, please indicate so now.

> It's now been two months since the last release, and there have been
> huge compiler improvements.
> Note also that there were a couple of very bad regressions in 2.052,
> so I think we really need a release ASAP.
> We've now achieved minimal stability again (all green on the auto-tester).
> 
> Here's the things which are blockers for the next release:
> 
> From the compiler side:
> * struct destruction of temporaries (seems like we have a chance of
> fixing this soon)
> * fixing the regressions from my CTFE/const folding changes (Fixes are
> here: https://github.com/D-Programming-Language/dmd/pull/37).
> * a few things haven't been backported to D1 yet
> druntime:
> * clean up Windows DLL support
> phobos:
> * nothing that I know of
> 
> Looks as though will be time to get std.parallelism in. But otherwise, if you have anything you'd like to get into the next release, please indicate so now.

I just put in a pull request for some fixes to std.datetime which should go in before the next release.

- Jonathan M Davis

2011/4/21 Don Clugston <dclugston at googlemail.com>:
> It's now been two months since the last release, and there have been
> huge compiler improvements.
> Note also that there were a couple of very bad regressions in 2.052,
> so I think we really need a release ASAP.
> We've now achieved minimal stability again (all green on the auto-tester).
>
> Here's the things which are blockers for the next release:
>
> From the compiler side:
> * struct destruction of temporaries (seems like we have a chance of
> fixing this soon)
> * fixing the regressions from my CTFE/const folding changes (Fixes are
> here: https://github.com/D-Programming-Language/dmd/pull/37).
> * a few things haven't been backported to D1 yet
> druntime:
> * clean up Windows DLL support
> phobos:
> * nothing that I know of
>
> Looks as though will be time to get std.parallelism in. But otherwise,
> if you have anything you'd like to get into the next release, please
> indicate so now.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Dmd has a bug that causes the @property attribute to be disregarded in
functions that return auto. Commit
https://github.com/D-Programming-Language/phobos/commit/1083bd4e7b4ef0475084d7eab2e67c65e511c3d4
introduced a definition of length in iota as

@property auto length()

which makes hasLength!iota(10) return false. (hasLength!iota(0, 10, 1)
returns true because its overload uses size_t). I suggest changing the
return type to Unsigned!Value if fixing the dmd behavior is
non-trivial.

I've also made a pull request for phobos that fixes a bug in std.algorithn.equal which causes equal("???", "???") to return false.

Torarin

Le 2011-04-21 ? 3:12, Don Clugston a ?crit :

> Looks as though will be time to get std.parallelism in. But otherwise, if you have anything you'd like to get into the next release, please indicate so now.

I'm just wondering how many DMD release will pass before my "const(Object)ref" pull request for DMD get reviewed. I don't want to push Walter too much, but the more he waits the more likely it won't merge so easily.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

Le 2011-04-21 ? 6:48, Torarin a ?crit :

> Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.

Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.

Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

As I've said before, we really need to decide whether @property has loose or
strict semantics.  Loose semantics means that non- at property functions would
still be callable without (), etc but @property functions wouldn't be
allowed to have ()s.  Frankly, I hate @property, want to to have as little
effect as possible,  like the flexibility of being able to call the same
function both ways, and would have a lot of code break if this were taken
away, so my vote is loose semantics.

On Thu, Apr 21, 2011 at 9:24 AM, Michel Fortin <michel.fortin at michelf.com>wrote:

> Le 2011-04-21 ? 6:48, Torarin a ?crit :
>
> > Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
>
> Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
>
> Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
>
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110421/8fa5e265/attachment.html>

On 4/21/2011 6:24 AM, Michel Fortin wrote:
> I'm just wondering how many DMD release will pass before my "const(Object)ref" pull request for DMD get reviewed. I don't want to push Walter too much, but the more he waits the more likely it won't merge so easily.
>

I understand. My current priority is to get temp destruction to work right. Following on is fixing fundamental issues with const, and getting disabling of default construction to work.

I've proposed in the past that functions which have no arguments and return void could be callable without parentheses, as they cannot be mistaken for properties.


I think we all agree that non- at property functions which take a single parameter should not be callable in property form.

Functions that are not properties which return a value should be required to have parentheses to distinguish them from properties.


The above is all consistent with TDPL as far as I know.


-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Thursday, April 21, 2011 10:09 AM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>As I've said before, we really need to decide whether @property has loose or strict semantics.? Loose semantics means that non- at property functions would still be callable without (), etc but @property functions wouldn't be allowed to have ()s.? Frankly, I hate @property, want to to have as little effect as possible,? like the flexibility of being able to call the same function both ways, and would have a lot of code break if this were taken away, so my vote is loose semantics.
>
>
>On Thu, Apr 21, 2011 at 9:24 AM, Michel Fortin <michel.fortin at michelf.com> wrote:
>
>Le 2011-04-21 ? 6:48, Torarin a ?crit :
>>
>>
>>> Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
>>
>>Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
>>
>>Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
>>
>>
>>--
>>Michel Fortin
>>michel.fortin at michelf.com
>>http://michelf.com/
>>
>>
>>
>>_______________________________________________
>>
>>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110421/e78bd37b/attachment-0001.html>

> As I've said before, we really need to decide whether @property has loose or strict semantics. Loose semantics means that non- at property functions would still be callable without (), etc but @property functions wouldn't be allowed to have ()s. Frankly, I hate @property, want to to have as little effect as possible, like the flexibility of being able to call the same function both ways, and would have a lot of code break if this were taken away, so my vote is loose semantics.

TDPL specifically gives it strict semantics. @property functions must be called without parens, and non- at property functions must be called with them. So, if we want to go with loose semantics, then TDPL will need to be changed.

Personally, I don't see much point to @property if its semantics are loose.

- Jonathan M Davis

On Thu, 21 Apr 2011 09:24:39 -0400, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2011-04-21 ? 6:48, Torarin a ?crit :
>
>> Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
>
> Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
>
> Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
>

Michel, does your patch also include fixes/additions to __traits and std.traits?