On Sunday, 2 October 2016 at 00:18:23 UTC, Basile B. wrote:
> It was compiling fine with 2.071.2. I cant say if this is a regression or not.
> If not it would mean that the previous management of the static ctor hided a problem ?

Yes, previously cyclic dependencies through a third module without ctor were not detected correctly. Therefore it was possible to use a module before it was initialized.

On Sunday, 2 October 2016 at 06:13:34 UTC, Suliman wrote:
> Sorry, but when new libs will be included?

We try to release regular and often (roughly every two month) to avoid such catch the train releases. Things should get released when they're ready, and only then.

On Sunday, 2 October 2016 at 12:43:00 UTC, Martin Nowak wrote:
> On Sunday, 2 October 2016 at 00:18:23 UTC, Basile B. wrote:
>> It was compiling fine with 2.071.2. I cant say if this is a regression or not.
>> If not it would mean that the previous management of the static ctor hided a problem ?
>
> Yes, previously cyclic dependencies through a third module without ctor were not detected correctly. Therefore it was possible to use a module before it was initialized.

This problem is fortunately fixed by moving a static ctor from a module to another but I still get some very strange messages saying "stuff does not override any function". Some of them are related to member functions with void() for type, so it cannot be an error in the signature.

The messages are not emitted when I unittest the module that contains the classes but only when I subclass in a simple script.

Does any change related to protection attributes would be able to trigger them ?
Such a breakage is really hardly believable (it's very basic OOP).

On Sunday, 2 October 2016 at 13:33:58 UTC, Basile B. wrote:
> Does any change related to protection attributes would be able to trigger them ?
> Such a breakage is really hardly believable (it's very basic OOP).

Please file a bug report with a code example reproducing the problem.
If you can't reduce the code, a big example is better than none.

On Sunday, 2 October 2016 at 15:04:06 UTC, Martin Nowak wrote:
> On Sunday, 2 October 2016 at 13:33:58 UTC, Basile B. wrote:
>> Does any change related to protection attributes would be able to trigger them ?
>> Such a breakage is really hardly believable (it's very basic OOP).
>
> Please file a bug report with a code example reproducing the problem.
> If you can't reduce the code, a big example is better than none.

Ok done: 16570 and 16574. I just tried to see if the problem was from my side before.

On 2016-10-02 14:37, Martin Nowak wrote:

> Yes, that's how it should be, but don't both deprecations contain enough
> information to replace old code?

Yeah, I see that now. I didn't notice it at first. It's not as clear as I would like. I would like it to explicitly state "To this instead: ...".

I think it could be more clear why it's deprecated and what to do instead:

Language construct A is deprecated.

A is bad because: ...
Do this instead: ...

-- 
/Jacob Carlborg

https://issues.dlang.org/show_bug.cgi?id=16578

On 2016-10-01 22:57, Martin Nowak wrote:

> Please report any bugs at https://issues.dlang.org

std.process is pretty broken on macOS: https://issues.dlang.org/show_bug.cgi?id=16580

-- 
/Jacob Carlborg

On Sunday, 2 October 2016 at 15:36:58 UTC, Jacob Carlborg wrote:
> I think it could be more clear why it's deprecated and what to do instead:
>
> Language construct A is deprecated.
>
> A is bad because: ...
> Do this instead: ...

Yes agreed, will try to establish a more formal format.