On Monday, 20 August 2018 at 00:14:03 UTC, Shigeki Karita wrote:
On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote:
Proof of concept works, but it requires some further
development to be useful to do work in.
[...]
Great. I have tried DUB integration. It seems to work.
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
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
On 09/03/2018 02:49 AM, Paul Backus wrote:
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa)
wrote:
Note that the above has *nothing* to do with retrieving a value.
Retrieving a value is merely used by the implementation as a trigger
to lazily decide whether the caller
On Sunday, 2 September 2018 at 15:51:37 UTC, lurker wrote:
if i remember correctly (5.), it wants a different/other
version of the tool chain.
never the less, i'll continue using c# and not install (1.)
again, since in earlier versions of D i eventually had to
deinstall VS2017 and then
On Sunday, 2 September 2018 at 22:04:11 UTC, Mike Franklin wrote:
I guess we should keep an eye on this for the next releases,
could you
take care of this Mike?
Take care of what exactly? What specifically needs to be done?
Testing Windows installation of at least the first beta and the
On Monday, 3 September 2018 at 06:00:06 UTC, Thomas Mader wrote:
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
There are generally two classic approaches to error handling:
std::expected is not the only thing on this topic going on in
C++.
There is also the proposal
On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote:
To me, the only acceptable choices are for `Expected!void` to
have the same lazy semantics as `Expected!T`, or for
`Expected!void` to be removed altogether. Having one
specialization be lazy and one be eager would be a nightmare
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky
(Abscissa) wrote:
Note that the above has *nothing* to do with retrieving a
value. Retrieving a value is merely used by the implementation
as a trigger to lazily decide whether the caller wants `foo` or
`tryFoo`. Going out of scope
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
There are generally two classic approaches to error handling:
std::expected is not the only thing on this topic going on in C++.
There is also the proposal from Herb Sutter [1].
It's not a library solution and changes even
10 matches
Mail list logo
