On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
> On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
>> On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
>>> Glad to announce D 2.079.0.
>>>
>>> This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details.
>>>
>>> Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors.
>>>
>>> http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html
>>>
>>> - -Martin
>>
>> Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag?
>>
>> Atila
>
> https://github.com/vibe-d/vibe.d/issues/2058

It's great that there's an issue for vibe.

This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org.

It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver!

I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.

I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen.

We have to do better than this.

Atila

On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
>
> I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen.
>
> We have to do better than this.
>
> Atila

Fair enough. Doing better is always a good thing to aim for.

But really, who use something 'just released' in production?

As far as I'm concerned, every release is a beta... even if the beta tag is removed.

The real problem is something you mentioned .. new comers downloading the latest release..which as I mentioned, is really a beta.

But that's just the way software developement works these days - sadly - ship quickly, and ship often. As a result, we're all just testers for the latest release.

Am 06.03.2018 um 00:40 schrieb Atila Neves:
> (...)
> 
> This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org.
> 
> It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver!
> 
> I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
> 
> I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen.
> 
> We have to do better than this.
> 
> Atila
> 

I tagged a RC today: https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/49899/

To avoid letting this sit broken I'll shorten the final testing phase, so that the release happens this Thursday. This is a bit unfortunate, because this release is a bit more disruptive than normal due to the switch to using vibe-core by default. So early testing with "dub upgrade --prerelease" in different projects is particularly valuable this time!

BTW, the problems with this release are a strong hint that we should rethink the inclusion approach with std.experimental. Since breaking changes are tied to the DMD version, it makes those modules almost unusable outside of toy code. Having them as a DUB package (or in essence, in a separate repository) on the other hand nicely decouples them from the compiler release and makes it possible to properly version them individually.

On Tuesday, 6 March 2018 at 00:10:52 UTC, Sönke Ludwig wrote:
>
> BTW, the problems with this release are a strong hint that we should rethink the inclusion approach with std.experimental. Since breaking changes are tied to the DMD version, it makes those modules almost unusable outside of toy code. Having them as a DUB package (or in essence, in a separate repository) on the other hand nicely decouples them from the compiler release and makes it possible to properly version them individually.

Additional evidence: std.experimental.ndslice -> libmir.

Can somebody explain how &array[0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore.

On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
> Can somebody explain how &array[0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore.


int[] a;
writeln(&arr[0]); // good - runtime produces a core.exception.RangeError
//writeln(arr.ptr); // what do you think will happen here?

On 3/5/18 15:40, Atila Neves wrote:
> On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
>> On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
>>> On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
>>>> Glad to announce D 2.079.0.
>>>>
>>>> This release comes with experimental `@nogc` exception throwing
>>>> (-dip1008), a lazily initialized GC, better support for minimal
>>>> runtimes, and an experimental Windows toolchain based on the lld
>>>> linker and MinGW import libraries. See the changelog for more details.
>>>>
>>>> Thanks to everyone involved in this 👏
>>>> https://dlang.org/changelog/2.079.0.html#contributors.
>>>>
>>>> http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html
>>>>
>>>> - -Martin
>>>
>>> Is is just me or did this release just break the latest non-beta
>>> vibe.d? Is the Jenkins build testing the dub packages on master
>>> instead of the latest tag?
>>>
>>> Atila
>>
>> https://github.com/vibe-d/vibe.d/issues/2058
>
> It's great that there's an issue for vibe.
>
> This doesn't change the fact that right now, somebody trying D for the
> 1st time with the latest official compiler will get an error if they try
> out the most popular dub package that I know of if they follow the
> instructions on code.dlang.org.
>
> It also doesn't change that I can't upgrade dmd on our CI at work
> because it can't compile vibe unless I change dozens of dub.sdl files to
> use a beta version. This breaks semver!
>
> I found out about this after removing a dependency on stdx.data.json
> since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed
> a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
>
> I'd have a snowball's chance in hell convincing anyone at a "regular"
> company of adopting D if anyone there even imagined any of the above
> could happen.
>
> We have to do better than this.
>
> Atila
>

May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :)

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d- announce wrote:
> On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote:
> > Can somebody explain how &array[0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore.
>
> int[] a;
> writeln(&arr[0]); // good - runtime produces a
> core.exception.RangeError
> //writeln(arr.ptr); // what do you think will happen here?

That example actually should be perfectly @safe, because the array is null, and it's using writeln. Dereferencing null is @safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's @safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's @safe too, even if the pointer value is garbage.

The problem is when the dynamic array's ptr points to something other than null, and its length is 0. a[0] does bounds checking, so &a[0] is only valid if the dynamic array's length is greater than 0, whereas a.ptr would happily give you a value even if the array's length is 0, and in that case, it's not valid to dereference that pointer. And depending on what that pointer points to, it could corrupt memory or access invalid memory if you dereference it.

So, in _most_ cases, using ptr is actually fine, but because it's not _always_ @safe, the compiler has to treat it as @system. It was previously thought to be fine, because the case where a dynamic array is empty but non-null had not been considered when deciding whether ptr could be used in @safe code.

- Jonathan m Davis

On Tuesday, 6 March 2018 at 00:08:33 UTC, psychoticRabbit wrote:
> On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote:
>>
>> I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen.
>>
>> We have to do better than this.
>>
>> Atila
>
> Fair enough. Doing better is always a good thing to aim for.
>
> But really, who use something 'just released' in production?

This is beside the point. Anyone who hears about vibe.d and goes to download the compiler to try it out will fail to get it to compile with the official instructions on how to do so.

It's hard enough to convince people to adopt a new programming language when everything works as intended.

Atila

On Tuesday, 6 March 2018 at 06:53:30 UTC, Adam Wilson wrote:
> On 3/5/18 15:40, Atila Neves wrote:
>> On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote:
>>> On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote:
>>>> On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote:
>>>>> [...]
>>>>
>>>> Is is just me or did this release just break the latest non-beta
>>>> vibe.d? Is the Jenkins build testing the dub packages on master
>>>> instead of the latest tag?
>>>>
>>>> Atila
>>>
>>> https://github.com/vibe-d/vibe.d/issues/2058
>>
>> It's great that there's an issue for vibe.
>>
>> This doesn't change the fact that right now, somebody trying D for the
>> 1st time with the latest official compiler will get an error if they try
>> out the most popular dub package that I know of if they follow the
>> instructions on code.dlang.org.
>>
>> It also doesn't change that I can't upgrade dmd on our CI at work
>> because it can't compile vibe unless I change dozens of dub.sdl files to
>> use a beta version. This breaks semver!
>>
>> I found out about this after removing a dependency on stdx.data.json
>> since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed
>> a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.
>>
>> I'd have a snowball's chance in hell convincing anyone at a "regular"
>> company of adopting D if anyone there even imagined any of the above
>> could happen.
>>
>> We have to do better than this.
>>
>> Atila
>>
>
> May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :)

The problem with that is I was waiting for 2.079.0 since it fixes a bug that prevented me from upgrading to any of the 2.078.x releases on Windows.

And then there's the fact that the last time I had issues upgrading gcc or clang was... never.

I'm more than ok with compiler upgrades breaking my code when it was wrong in the 1st place, or with language updates breaking code but making the situation better as a whole. That's not what's been happening to me with the last few versions.

Atila