On Thursday, 20 September 2018 at 10:48:35 UTC, Atila Neves wrote:
What's the fix? Have the compiler insert a call to the
exception's destructor at the end of the `catch(scope
Exception)` block.
If I understood you correctly then we have same idea. If
exception is not handled or re thrown
On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote:
On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi
wrote:
If `@nogc` could be relaxed for `new Error` exactly for that
reason, pieces of Phobos could be turned `@nogc`...
But I admit that that change would be
On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi
wrote:
If `@nogc` could be relaxed for `new Error` exactly for that
reason, pieces of Phobos could be turned `@nogc`...
But I admit that that change would be controversial...
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven
Schveighoffer wrote:
On 9/20/18 12:24 PM, Adam D. Ruppe wrote:
On Thursday, 20 September 2018 at 15:52:03 UTC, Steven
Schveighoffer wrote:
I needed to know what the slice parameters that were failing
were.
Aye. Note that RangeError is
On Friday, 19 October 2018 at 23:46:29 UTC, Nicholas Wilson wrote:
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which renders dip1008 pretty much useless
since we could already use static
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code
On Friday, 21 September 2018 at 11:48:50 UTC, Nemanja Boric wrote:
On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric
wrote:
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
The @__future is fully (to a reasonable degree) implemented -
and the
On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric wrote:
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
The @__future is fully (to a reasonable degree) implemented -
and the `Throwable.message` was marked with this attribute to
prevent breaking the
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis
wrote:
[...]
I think that the message member was added by Dicebot as an
attempt to fix this issue, because Sociomantic needed it, but I
don't know exactly what's going on with that or @__future.
- Jonathan M Davis
The @__future
On Wednesday, September 19, 2018 3:16:00 PM MDT Steven Schveighoffer via
Digitalmars-d wrote:
> Given dip1008, we now can throw exceptions inside @nogc code! This is
> really cool, and helps make code that uses exceptions or errors @nogc.
> Except...
I pointed out this problem when the DIP was
On 9/20/18 1:58 PM, Adam D. Ruppe wrote:
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote:
I don't know how a performance problem can occur on an error being
thrown anyway -- the process is about to end.
Walter's objection was code size - it would throw stuff out of
On Thursday, 20 September 2018 at 15:52:15 UTC, H. S. Teoh wrote:
Yeah, that's what I meant. :D Well, for backward compatibility
we could still have .msg allocate and return a string, but we
could provide an overload / alternate member function that
writes directly to a sink instead. Then we
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven
Schveighoffer wrote:
I don't know how a performance problem can occur on an error
being thrown anyway -- the process is about to end.
Walter's objection was code size - it would throw stuff out of
cache lines, even if it doesn't need to
On 9/20/18 12:24 PM, Adam D. Ruppe wrote:
On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote:
I needed to know what the slice parameters that were failing were.
Aye. Note that RangeError is called by the compiler though, so you gotta
patch dmd to make it pass the
On Thursday, 20 September 2018 at 15:52:03 UTC, Steven
Schveighoffer wrote:
I needed to know what the slice parameters that were failing
were.
Aye. Note that RangeError is called by the compiler though, so
you gotta patch dmd to make it pass the arguments to it for
index. Ugh. I did a PR for
On 9/20/18 11:33 AM, Adam D. Ruppe wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven Schveighoffer
wrote:
As Andrei says -- Destroy!
Nah, I agree. Actually, I'm of the opinion that string error messages in
exceptions ought to be considered harmful: you shouldn't be doing
On Thu, Sep 20, 2018 at 11:25:27AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
> On 9/20/18 11:06 AM, H. S. Teoh wrote:
[...]
> > IIRC, originally the stacktrace was also built at exception
> > construction time. But it was causing a major performance hit, so
> > eventually someone
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
As Andrei says -- Destroy!
Nah, I agree. Actually, I'm of the opinion that string error
messages in exceptions ought to be considered harmful: you
shouldn't be doing strings at all. All the useful information
On 9/20/18 11:06 AM, H. S. Teoh wrote:
On Thu, Sep 20, 2018 at 08:48:13AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
But this means you still have to build msg when throwing the
error/exception. It's not needed until you print it, and there's no
reason anyway to make it
On Thu, Sep 20, 2018 at 08:48:13AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> But this means you still have to build msg when throwing the
> error/exception. It's not needed until you print it, and there's no
> reason anyway to make it allocate, even with RAII. For some reason D
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
[...]
I expressed my concern for DIP1008 and the `msg` field when it
was first announced. I think
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven Schveighoffer
wrote:
Given dip1008, we now can throw exceptions inside @nogc code! This is
really cool, and helps make code that uses exceptions or errors @nogc.
Except...
The mechanism to report
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code that uses exceptions
or errors @nogc. Except...
The mechanism to report what actually went wrong for an
On 9/19/18 7:53 PM, Seb wrote:
On Wednesday, 19 September 2018 at 21:28:56 UTC, Steven Schveighoffer
wrote:
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message @nogc,
but in actuality, it could be.
We recently introduced support for
On Wednesday, 19 September 2018 at 21:28:56 UTC, Steven
Schveighoffer wrote:
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message
@nogc, but in actuality, it could be.
We recently introduced support for output ranges in the
formatting
On 9/19/18 5:16 PM, Steven Schveighoffer wrote:
One further thing: I didn't make the sink version of message @nogc, but
in actuality, it could be. Notice how it allocates using the stack. Even
if we needed some indeterminate amount of memory, it would be simple to
use C malloc/free, or alloca.
Given dip1008, we now can throw exceptions inside @nogc code! This is
really cool, and helps make code that uses exceptions or errors @nogc.
Except...
The mechanism to report what actually went wrong for an exception is a
string passed to the exception during *construction*. Given that you
28 matches
Mail list logo
