"Jakob Ovrum"  wrote in message news:whwxxduozvqjrcldmggt@forum.dlang.org...
> Alright, that looks more short-term viable than Stepanov's approach. I don't think I'm overplaying the issue though - it is a tall order to ask for compile-time construction of AAs that are then usable at runtime, and it's not fair to present them as a fundamental feature, or their absence as a bug, because it's not like other languages have anything near this kind of power.

This used to be true, but now we can pass heap-allocated structs and classes from compile-time to run-time.  The fact we can't do the same for AAs is an embarrassing limitation.

It would have happened years ago if AAs weren't such a mess. 

On 12 January 2014 21:02, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.334.1389499497. 15871.digitalmars-d@puremagic.com...
>
>  I've just run into this again today. It's still very annoying.
>> Consider this a reminder? :)
>>
>
> AAs should be rolled back first, and these have been sitting there for a couple of months.
>
> https://github.com/D-Programming-Language/dmd/pull/2856 https://github.com/D-Programming-Language/druntime/pull/668
>
> Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’.
>

I'm often surprised that a semi-official fork has never appeared ;)

When is the next release meant to be? I saw comments in those bugs that it was supposed to be in December, but that seems too soon?

On Sunday, 12 January 2014 at 14:30:42 UTC, Daniel Murphy wrote:
> This used to be true, but now we can pass heap-allocated structs and classes from compile-time to run-time.  The fact we can't do the same for AAs is an embarrassing limitation.

This ability for class instances is fairly recent, but the same point remains - being able to instantiate a class at compile-time and use it at runtime is equally a tall order, not a fundamental feature, and it wasn't a bug when it was absent.

"Jakob Ovrum"  wrote in message news:yvvcvcfughejigooefua@forum.dlang.org...
> This ability for class instances is fairly recent, but the same point remains - being able to instantiate a class at compile-time and use it at runtime is equally a tall order, not a fundamental feature, and it wasn't a bug when it was absent.

I disagree.  Being able to pass classes from ctfe to run-time is a fundamental feature of ctfe.  AAs are even more important, as no ctfe is required to hit this limitation. 

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.355.1389539511.15871.digitalmars-d@puremagic.com...
> I'm often surprised that a semi-official fork has never appeared ;)

I don't agree with everything Walter does, but that doesn't mean I want his job.

> When is the next release meant to be? I saw comments in those bugs that it was supposed to > be in December, but that seems too soon?

When all regressions are fixed + when Walter says so + when the moon is in the correct phase 

On 1/12/14 3:02 AM, Daniel Murphy wrote:
> "Manu" <turkeyman@gmail.com> wrote in message
> news:mailman.334.1389499497.15871.digitalmars-d@puremagic.com...
>> I've just run into this again today. It's still very annoying.
>> Consider this a reminder? :)
>
> AAs should be rolled back first, and these have been sitting there for a
> couple of months.
>
> https://github.com/D-Programming-Language/dmd/pull/2856
> https://github.com/D-Programming-Language/druntime/pull/668
>
> Walter has decided that this coming release will only be bugfixes...
> kind of a useless thing to do for an open source project, as him
> refusing to review/merge my enhancement pulls doesn’t inspire me to work
> on ‘actual bugs’.

If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong.

Andrei

"Andrei Alexandrescu"  wrote in message news:laugvv$2k3h$1@digitalmars.com...
> If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong.

I don't know if it's undue or not, but
https://github.com/D-Programming-Language/dmd/pull/2895
https://github.com/D-Programming-Language/dmd/pull/2924 

On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu
wrote:
> On 1/12/14 3:02 AM, Daniel Murphy wrote:
>> "Manu" <turkeyman@gmail.com> wrote in message
>> news:mailman.334.1389499497.15871.digitalmars-d@puremagic.com...
>>> I've just run into this again today. It's still very annoying.
>>> Consider this a reminder? :)
>>
>> AAs should be rolled back first, and these have been sitting there for a
>> couple of months.
>>
>> https://github.com/D-Programming-Language/dmd/pull/2856
>> https://github.com/D-Programming-Language/druntime/pull/668
>>
>> Walter has decided that this coming release will only be bugfixes...
>> kind of a useless thing to do for an open source project, as him
>> refusing to review/merge my enhancement pulls doesn’t inspire me to work
>> on ‘actual bugs’.
>
> If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong.
>
> Andrei

The Release Process on the wiki[1] does not have a method for a
bugfix only release so it's definitely a problem. Both bugfixes
and features get merged into master.

The release process forbids cherry-picking between branches (some
rationale for this rule would be nice; it feels like a mistake to
me) so that can't be used to solve the problem. I don't think
there is a way to do a bugfix only release without cherry-picking.

If it were me, I'd just would have had both bugfixes and features
merge into master as described by the release process and have a
2.065 branch which a single person is responsible for
cherry-picking bugfixes into (alternatively you could have
whoever merges the bugfix into master do it).

Frankly, I think the described Release Process is much more
complicated than it needs to be. Fundamentally you only need two
branches at any given time: master and a release branch which
only exists after the feature freeze takes place for an upcoming
release (post-release the branch gets tagged, merged back into
master[2], and deleted).

It's a shame Github doesn't let you target multiple branches with
a pull request. That'd be a nice workflow during the short lived
feature freeze window.

1. http://wiki.dlang.org/Release_Process
2. Which, I found out by chance, never happens:
https://github.com/D-Programming-Language/dmd/pull/3080 This is
very bad as commits can easily get lost though I question whether
the release branch should ever be committed to directly.

On Sunday, 12 January 2014 at 19:45:15 UTC, Brad Anderson wrote:
> On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu
> wrote:
>> If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong.
>>
>> Andrei
>
> The Release Process on the wiki[1] does not have a method for a
> bugfix only release so it's definitely a problem. Both bugfixes
> and features get merged into master.
>
> The release process forbids cherry-picking between branches (some
> rationale for this rule would be nice; it feels like a mistake to
> me) so that can't be used to solve the problem. I don't think
> there is a way to do a bugfix only release without cherry-picking.
>
> If it were me, I'd just would have had both bugfixes and features
> merge into master as described by the release process and have a
> 2.065 branch which a single person is responsible for
> cherry-picking bugfixes into (alternatively you could have
> whoever merges the bugfix into master do it).
>
> Frankly, I think the described Release Process is much more
> complicated than it needs to be. Fundamentally you only need two
> branches at any given time: master and a release branch which
> only exists after the feature freeze takes place for an upcoming
> release (post-release the branch gets tagged, merged back into
> master[2], and deleted).


I had to get this off my chest even if it's unlikely to be
adopted:

http://wiki.dlang.org/Simplified_Release_Process_Proposal

On 1/12/14 2:27 PM, Brad Anderson wrote:
> I had to get this off my chest even if it's unlikely to be
> adopted:
>
> http://wiki.dlang.org/Simplified_Release_Process_Proposal

cc Andrew Edwards

Andrei