Glad to announce D 2.073.0.

This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes.

http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html

-Martin

On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:
> Glad to announce D 2.073.0.
>
> This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html
>
> -Martin

Thanks for this release and especially for having handled the new regressions.

On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:
> Glad to announce D 2.073.0.
>
> This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html
>
> -Martin

<3

On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:
> Glad to announce D 2.073.0.
>
> This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html
>
> -Martin

Thank you!

On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:
> Glad to announce D 2.073.0.
>
> This release comes with a few phobos additions, new -mcpu=avx and -mscrt switch, and several bugfixes.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.073.0.html
>
> -Martin

Can we have some love for Windows COM and extern C++ ABI regarding return struct by value for next release, please?

I mean there is already few bug reports[1,2] on that matter. For example when return struct with 2 floats first one goes to ECX, second to EDX, DMD got only the second one. In x64 it is even worse, in most cases it just crashes. And LDC crashes in both x86/x64, so... can't use D at all.

It is a real blocker which prevents from using D in some areas, like DirectX (for example Direct2D is what used to make fast and effecient 2d rendering for UI, sure this is not the only way but it is native!)

there was also a thread not so long ago - http://forum.dlang.org/post/tiyttpodenppvlfxixcw@forum.dlang.org

[1] https://issues.dlang.org/show_bug.cgi?id=16987
[2] https://issues.dlang.org/show_bug.cgi?id=16527

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

Can I have my "I told you so" badge please?

And also stuff like https://github.com/dlang/druntime/pull/1740 - I think the story behind `return scope` is the critical point for me. It is worst technical disaster that has happened to compiler in years, and I am going to blame Walter personally for it.

On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:
> And also stuff like https://github.com/dlang/druntime/pull/1740

Why it would break code if `in` meant `scope`?

On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:
> And also stuff like https://github.com/dlang/druntime/pull/1740 - I think the story behind `return scope` is the critical point for me. It is worst technical disaster that has happened to compiler in years, and I am going to blame Walter personally for it.

So what would the alternative be?

On 01/27/2017 01:29 PM, Nordlöw wrote:
> On Friday, 27 January 2017 at 11:12:22 UTC, Dicebot wrote:
>> And also stuff like https://github.com/dlang/druntime/pull/1740 - I think the story behind `return scope` is the critical point for me. It is worst technical disaster that has happened to compiler in years, and I am going to blame Walter personally for it.
> 
> So what would the alternative be?

Alternative would be to implement new functionality like a responsible developer - keep it in sync with specification document, design set of acceptance tests and do all the development in a separate branch until is verified to both have desired semantics and don't cause any breakage in existing projects. And don't rush into forcing usage of half-done feature inside standard library the very moment it got released.