On 3/5/18 6:40 PM, 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.

std.experimental is supposed to be allowed to be broken.

That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version.

-Steve

On 3/6/18 2:11 AM, Jonathan M Davis wrote:
> 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.

Yeah, a better example:

struct S
{
   size_t[1] x;
   int *bad;
}

void foo() @safe
{
   S s;
   auto arr = s.x[$ .. $];
   // int *p = &arr[0]; // would throw range error
   auto p = arr.ptr; // this now points at bad
   *p = 0xdeadbeef;
   *s.bad = 5; // oops
}

-Steve

On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote:
>
> 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.
>

my point had nothing to do with writeln.

my point was, that a RangeError exception may help save the day, but not when you use .ptr

thankfully Steven gave a much better example to make the point clearer ;-)

(I assume that int is meant to be size_t)

On 3/6/18 11:13 AM, psychoticRabbit wrote:

> (I assume that int is meant to be size_t)

Yes, I changed the uncommented one to auto after I realized, but not the commented one ;)

-Steve

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
> That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository.

Just showing that phobos is not the right place to develop modules/packages, also mir.
IMO std.experimental provides little benefit over dub, but comes with many downsides.

> This allows selection of the dependency on std.experimental separate from phobos.

You cannot link against diamond dependencies of different versions though, so we'd have to exclude it from libphobos and put it separately.

> It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website.

Not sure why inclusion in distribution is often mentioned as such a thing.
It's trivial and common to have separate libraries/dependencies in every language with a healthy ecosystem.

> But if needed, you could have your dub package depend on a prior version.

http://code.dlang.org/packages/stdx-allocator ;)

On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote:
> 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.

I think 2.078 would make an excellent starting point for a LTS because of the important fixes that only made it to 2.079. If anyone is interested to backport fixes and maintain such a source-branch, please contact me.

On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote:
> Good stuff. Still bothers me that we had to special case "throw new Exception();" in order to make it nogc. I can't think of any better ways right now

Implementing EH for values (instead of class references) would have been a lot more complex.

> but I wish it was more explicit.

Initially people always want more explicitness for new, not yet too well known, features, while later opting for terser syntax for commonly used things.
Exceptions are supposed to be rare and deleting them directly after being catched seemed like a reasonable enough default to go with the specialization.
After all it solves a huge problem, error handling in @nogc code.
Maybe we'll find a better/cleaner solution when more of the language has been transitioned to @safe @nogc.

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.

&array[0] is runtime bounds-checked
array.ptr is unchecked and might return an out-of-bounds pointer (to the first element)

On 3/6/18 2:30 PM, Martin Nowak wrote:
> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:

>> But if needed, you could have your dub package depend on a prior version.
> 
> http://code.dlang.org/packages/stdx-allocator ;)
> 

This is the answer, vibe.d should depend on stdx-allocator.

-Steve

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
> That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version.

The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules.

Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?