Re: LDC 1.12.0-beta1
On Tuesday, 4 September 2018 at 23:03:30 UTC, Arun Chandrasekaran wrote: On Tuesday, 4 September 2018 at 22:47:39 UTC, kinke wrote: Glad to announce the first beta for LDC 1.12: * Based on D 2.082.0. * LTO working for Win64 targets. * IR-based PGO working for Windows targets. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta1 Thanks to all contributors! Fantastic work! This is the first time LDC caught up with DMD in a single day, I guess. No, kinke has had this down before, as the first 1.10 beta came out within two weeks and the 1.11 beta came out on the same day as its upstream dmd: https://forum.dlang.org/thread/lyzbdiqcnohbvphzg...@forum.dlang.org https://forum.dlang.org/thread/gpeecjveashtvfpih...@forum.dlang.org This _is_ the first time we're releasing a native build of LDC for linux/AArch64 on the release date, because of the work kinke did to add a Linux/AArch64 CI for LDC, which also automatically uploads the release build. 1.11 was the first release with an AArch64 build, but that was added manually a week later, as can be seen from the datestamps here: http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I'll add native beta builds for Android in a couple days.
Re: LDC 1.12.0-beta1
On Tuesday, 4 September 2018 at 22:47:39 UTC, kinke wrote: Glad to announce the first beta for LDC 1.12: * Based on D 2.082.0. * LTO working for Win64 targets. * IR-based PGO working for Windows targets. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta1 Thanks to all contributors! Fantastic work! This is the first time LDC caught up with DMD in a single day, I guess.
LDC 1.12.0-beta1
Glad to announce the first beta for LDC 1.12: * Based on D 2.082.0. * LTO working for Win64 targets. * IR-based PGO working for Windows targets. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta1 Thanks to all contributors!
Re: expectations 0.1.0
On 09/04/2018 12:05 AM, Paul Backus wrote: On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) wrote: By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothing happens. That's called squelching an error, and its EXACTLY the same problem as using non-Expect return values to indicate errors. I'd regard that as very notable hole in any Expected design as it breaks one of the core points of using Expect vs returning plain error codes: The user can still accidentally (or deliberately) squelch an error. If you receive an `Expected!T`, you have the following choices available to you: 1. Handle the success case locally, and the failure case non-locally (i.e. use `value` directly). 2. Handle both the success case and the failure case locally (i.e. check `hasValue`). 3. Handle both the success case and the failure case non-locally (i.e., pass the `Expected!T` along untouched). The difference between `Expected`, on the one hand, and both `Success` and plain-old exceptions, on the other, is that `Expected` gives you choice #3, and the other two don't. I think you may be getting hung up on a certain particular detail of Vladimir's exact "draft" implementation of Success, whereas I'm focusing more on Success's more general point of "Once the object is no longer around, guarantee the error doesn't get implicitly squelched." You're right that, *in the draft implementation as-is*, it can be awkward for the caller to then pass the Success along to some other code (another function call, or something higher up the stack). *Although*, still not impossible. So #3 still isn't eliminated, it's simply made awkward... But reference counting would be enough to fix that. (Or a compiler-supported custom datatype that's automatically pass-by-moving, but that's of course not something D has). And you haven't actually directly addressed the issue I've raised about failing to guarantee errors aren't implicitly squelched. Why is choice #3 important? Because it doesn't branch. Both success and failure follow the same code path. That makes functions that use `Expected` much easier to compose than ones that throw exceptions. For example, if you throw an exception in the middle of a range pipeline, the entire thing comes crashing down--but an `Expected!T` will pass right through, and let you handle it when it comes out the other end. Right. And as described above, I'm advocating an approach that preserves that (even for void) while *also* improving Expect so it can not *merely* improve things "in most cases", but would actually *guarantee* errors are not implicitly squelched in ALL cases where Expect!whatever is used. I don't see the laziness here as being the core point. The laziness is the "how", not the raison d'etre. The laziness is simply a tool being used to achieve the real goals of: - Allowing the caller the decide between foo/tryFoo versions without the API duplication. - Decreasing exception-related overhead and increasing utility of nothrow. The laziness (on the part of the caller, i.e., the code that *receives* the `Expected!T`) is important because it's what makes choice #3 possible. It's an essential part of the design. Again, what I'm proposing still preserves that.
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this approach to error handling in considerable detail. expectations 0.2.0 is now available, with the following updates - `hasValue`, `value`, and `exception` now work for const and immutable `Expected` objects. - `Expected!void` has been removed. - `map` and `andThen` can now be partially applied to functions, "lifting" them into the Expected monad. - The documentation has been improved based on the feedback given in this thread.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: Glad to announce D 2.082.0. This release comes with more efficient update functions for associative arrays, unsafe code in debug blocks, UDAs for function parameters, an improved dependency resolution and avoidance of online update checks for dub, and signed Windows binaries. The blog announcement: https://dlang.org/blog/2018/09/04/dmd-2-082-0-released/ Reddit: https://www.reddit.com/r/programming/comments/9cw2mp/release_20820_of_dmd_the_d_reference_compiler/
Re: Release D 2.082.0
On Tuesday, 4 September 2018 at 10:51:32 UTC, Martin Nowak wrote:
On Tuesday, 4 September 2018 at 03:56:25 UTC, Shigeki Karita
wrote:
Is there any workaround to avoid this?
Please file a regression under https://issues.dlang.org/.
One workaround for now would be to initialize the variable at
runtime, e.g.
```d
static double d;
shared static this() { d = exp(-1.0); }
```
I reported it there. Thanks.
Re: Release D 2.082.0
On Tuesday, 4 September 2018 at 03:56:25 UTC, Shigeki Karita
wrote:
Is there any workaround to avoid this?
Please file a regression under https://issues.dlang.org/.
One workaround for now would be to initialize the variable at
runtime, e.g.
```d
static double d;
shared static this() { d = exp(-1.0); }
```
Re: expectations 0.1.0
On Monday, 3 September 2018 at 13:00:05 UTC, aliak wrote: This would be great to have in D. Indeed, if it's really going into C++ D needs to think about how to handle that anyway if it wants to offer C++ ABI interfacing. Swift [0] has something similar, and personally after using it for a few years, I can say that I've seen next to no unhandled exception errors in iOS code at least. Thanks, didn't know that Swift is already using something like this.
