On 11/9/13 9:10 AM, Kelet wrote:
> Are there any plans for adding compile-time checking or recursive
> data types to std.variant's Algebraic? I think algebraic data
> types are important and the current implementation is not
> suitable to solve a good portion of problems that the intended
> implementation could.
>
> Could this be a possible goal for 2.065? If not, are we lacking
> demand? Lacking someone willing to work on it?

Yah, I think we should add that. Please add it to the wiki.

Andrei

On 11/8/13 12:09 PM, Martin Nowak wrote:
> I made a wiki page for that.
> Please discuss, improve and prioritize.
> http://wiki.dlang.org/Agenda

IMHO, this shouldn't become a wish list of what individuals want the.  It should be a list of what is actually being worked on.  Don't add to this list unless you yourself are doing the work.

On 11/09/2013 08:41 PM, Brad Roberts wrote:
>
> IMHO, this shouldn't become a wish list of what individuals want the.
> It should be a list of what is actually being worked on.  Don't add to
> this list unless you yourself are doing the work.

Yep, but seems to work out.

On Sat, Nov 9, 2013 at 9:46 AM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 11/9/13 9:10 AM, Kelet wrote:
>
>> Are there any plans for adding compile-time checking or recursive data types to std.variant's Algebraic? I think algebraic data types are important and the current implementation is not suitable to solve a good portion of problems that the intended implementation could.
>>
>> Could this be a possible goal for 2.065? If not, are we lacking demand? Lacking someone willing to work on it?
>>
>
> Yah, I think we should add that. Please add it to the wiki.
>
> Andrei
>
>
Regarding recursive/nested variants I posted code back in June:
thread:
http://forum.dlang.org/thread/xaganckgcdkfcmjamogh@forum.dlang.org#post-mailman.1054.1371029915.13711.digitalmars-d:40puremagic.com
code:
https://github.com/timotheecour/dtools/blob/master/dtools/util/variant_nested.d

Release early and often should be the way to go (cf chrome release cycle) Less pain upgrading from release to release, less pain merging pull requests. All this requires is automated release tool.


On Sat, Nov 9, 2013 at 5:24 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-09 07:47, Martin Nowak wrote:
>
>  I choose march because ~4 month is already an improvement.
>> Anything below 3 month seems unrealistically ambitious to me atm.
>>
>
> It depends on what we want to achieve. Either we set the agenda after a release schedule. Or we do it the other way around. I know Iain has been complaining when releases are taking longer time.
>
> BTW, do people in general have more or less time working on D during the Christmas? I know I will have more time.
>
> --
> /Jacob Carlborg
>

On Sat, Nov 9, 2013 at 3:33 AM, Jacob Carlborg <doob@me.com> wrote:

> On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:
>
>  runtime loading of shared libraries on OSX, so that it works as on linux
>> I see b/10440 fixed in changelog, however does that mean it should work as safely as on linux? (both runtime and nonruntime libs)
>>
>
> Unfortunately no. I think the biggest obstacle is TLS. DMD emulates TLS on Mac OS X, which doesn't really work with dynamic libraries. It didn't exist natively on Mac OS X when DMD for D2 was ported to Mac OS X. I guess that best option is that DMD start to use native TLS. That would mean we need to drop support for Mac OS X Snow Leopard (10.6). Unless we move the part of the dynamic linker that handles TLS to druntime, which I think is technially possible.
>

10.6 is 3 releases old, it would be acceptable. Should we use a quick poll ( https://www.surveymonkey.com/) to vote for it?


>
> Except from that I think it might be easier to implement support for dynamic libraries on Mac OS X. The dynamic linker on Mac OS X has a much broader API than on Linux. We can use more of the existing functions there.
>
> --
> /Jacob Carlborg
>

On 2013-11-10 00:32, Timothee Cour wrote:

> 10.6 is 3 releases old, it would be acceptable. Should we use a quick
> poll (https://www.surveymonkey.com/) to vote for it?

Yes, it might be time to rethink that, now when Maverick has been released.

-- 
/Jacob Carlborg

On 11/8/2013 12:09 PM, Martin Nowak wrote:
> I made a wiki page for that.
> Please discuss, improve and prioritize.
> http://wiki.dlang.org/Agenda

My agenda for 2.065 is to cut down the size of the outstanding bug list.

Brad Roberts:

> IMHO, this shouldn't become a wish list of what individuals want the.  It should be a list of what is actually being worked on.  Don't add to this list unless you yourself are doing the work.

I think dmd 2.065 should focus on (some of) the unfinished parts of the language, and the eventually needed small breaking changes caused by that implementation. (So I don't like dmd 2.065 to focus on ICEs).

Bye,
bearophile

On 12 November 2013 12:51, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/8/2013 12:09 PM, Martin Nowak wrote:
>
>> I made a wiki page for that.
>> Please discuss, improve and prioritize.
>> http://wiki.dlang.org/Agenda
>>
>
> My agenda for 2.065 is to cut down the size of the outstanding bug list.
>

How about the rvalue-temp -> ref thing? That's getting REALLY tired.