On Tuesday, 13 December 2016 at 22:47:55 UTC, Andrei Alexandrescu
wrote:
On 12/13/2016 05:05 PM, Jonathan M Davis wrote:
Recall that all AssertError instances are equivalent up to file
and line.
They also have a message. AssertErrors aren't any more the same
as each other than any other
On 12/13/2016 05:05 PM, Jonathan M Davis wrote:
I mean that with virtual functions, in contracts get ||ed and out
contracts get & Since that involves assertions, unless the compiler
is doing something special there with assert, that involves throwing
multiple AssertErrors and catching them.
On Tuesday, 13 December 2016 at 06:36:47 UTC, Shachar Shemesh
wrote:
On 13/12/16 02:57, Andrei Alexandrescu wrote:
You can catch AssertError. There's no guarantees dtors have
been called
during unwinding. -- Andrei
That makes no sense to me, unless you only want to catch it in
order to do
On Tuesday, 13 December 2016 at 22:15:13 UTC, Stefan Koch wrote:
I have noticed severe code-bloat at ctfe, and worse when
ctfe-codegen miscompiles those templates,
there in way to know why!
Was meant to say.
there is no way to know why.
On Tuesday, 13 December 2016 at 18:52:05 UTC, Andrei Alexandrescu
wrote:
* People have noticed that certain simple uses of D trigger
calls into druntime that are not quite justified. For example,
assigning an array of int to another array of int issues a call
into a function that uses dynamic
On Tuesday, 13 December 2016 at 13:59:13 UTC, Andrei Alexandrescu
wrote:
On 12/13/2016 01:34 AM, Shachar Shemesh wrote:
unlinking GC from phobos is not likely to happen until that
happens
You can avoid linking druntime today with -betterC. -- Andrei
You can avoid linking druntime _now_. And
On Tuesday, 13 December 2016 at 04:45:35 UTC, Andrei Alexandrescu
wrote:
On 12/12/16 11:07 PM, Jonathan M Davis wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei
Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from
On Tuesday, 13 December 2016 at 11:39:16 UTC, Guillaume Piolat
wrote:
On Monday, 12 December 2016 at 21:02:11 UTC, Andrei
Alexandrescu wrote:
That will come too.
Andrei
Great teaser :)
For reference, here is how I currently do this:
- make Object.~this() @nogc with a cast
- throw
On 12/13/2016 01:23 AM, Shachar Shemesh wrote:
On 12/12/16 23:02, Andrei Alexandrescu wrote:
Why am I not surprised :o).
I'm not sure what to make of that comment.
Just jesting, and not always in style. Apologies. Let me restate the
factors at play here; admittedly the matter is a bit
On 12/13/2016 12:18 PM, Timon Gehr wrote:
I assume you don't refer to passing along a runtime flag whether
execution is currently in a contract and then selectively disable
calling of dtors.
No, something simpler than that - nontransitive. Consider:
T fun(R range)
in
{
assert(range.front
On 13.12.2016 17:47, Andrei Alexandrescu wrote:
On 12/13/2016 11:39 AM, Timon Gehr wrote:
On 13.12.2016 01:57, Andrei Alexandrescu wrote:
On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
Of course, then you'll find the fun of all the tests (and probably
code)
that catch AssertError.
On 12/13/2016 11:39 AM, Timon Gehr wrote:
On 13.12.2016 01:57, Andrei Alexandrescu wrote:
On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
Of course, then you'll find the fun of all the tests (and probably code)
that catch AssertError.
You can catch AssertError. There's no
On 13.12.2016 01:57, Andrei Alexandrescu wrote:
On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
Of course, then you'll find the fun of all the tests (and probably code)
that catch AssertError.
You can catch AssertError. There's no guarantees dtors have been called
during unwinding.
On 12/13/2016 01:34 AM, Shachar Shemesh wrote:
unlinking GC from phobos is not likely to happen until that happens
You can avoid linking druntime today with -betterC. -- Andrei
On Tuesday, 13 December 2016 at 07:49:59 UTC, Jacob Carlborg
wrote:
On 2016-12-13 05:07, Jonathan M Davis wrote:
It also could be problematic with unit tests - especially unit
tests that catch AssertErrors (e.g. if someone wants to test
the
contracts).
I also expect all unit test
On Monday, 12 December 2016 at 21:02:11 UTC, Andrei Alexandrescu
wrote:
That will come too.
Andrei
Great teaser :)
For reference, here is how I currently do this:
- make Object.~this() @nogc with a cast
- throw emplaced exceptions in malloc'd memory
- release them explicitely at catch
On Tuesday, 13 December 2016 at 06:36:47 UTC, Shachar Shemesh
wrote:
Also, please note that not all non-Exception Throwables are
terminal for the process. We use a Throwable that is not an
Exception in order to force termination of a fiber from outside
in a clean way. If proper unwinding is
On 2016-12-13 05:07, Jonathan M Davis wrote:
It also could be problematic with unit tests - especially unit
tests that catch AssertErrors (e.g. if someone wants to test the
contracts).
I also expect all unit test frameworks that are slightly more advanced
then the built-in we have now would
On 13/12/16 02:57, Andrei Alexandrescu wrote:
You can catch AssertError. There's no guarantees dtors have been called
during unwinding. -- Andrei
That makes no sense to me, unless you only want to catch it in order to
do something right before exiting anyways.
Also, please note that not
On 13/12/16 06:45, Andrei Alexandrescu wrote:
I agree the perfect system would fix everything - problem is we don't
have it yet. The per-thread singleton is a step forward (which at some
point we should probably make publicly available).
Andrei
If it's not going to be needed once exceptions
On 12/12/16 23:02, Andrei Alexandrescu wrote:
On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
On 12/12/16 17:51, Andrei Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons -
On 12/12/16 11:07 PM, Jonathan M Davis wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons - multiple objects in
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu
wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think
all Errors should be singletons - multiple objects in that
hierarchy arguably make no sense. But of
On Monday, 12 December 2016 at 21:02:11 UTC, Andrei Alexandrescu
wrote:
On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
Now, if you'd make regular Exceptions GC free
That will come too.
Then why bother making Errors singletons in order to avoid the
GC? The problem you're trying to fix
On Tuesday, 13 December 2016 at 03:07:56 UTC, Dsby wrote:
On Monday, 12 December 2016 at 17:57:13 UTC, Adam D. Ruppe
wrote:
On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
Wouldn't it break chained assertion errors?
An Error is unrecoverable anyway, if such a case arises it can
On Monday, 12 December 2016 at 17:57:13 UTC, Adam D. Ruppe wrote:
On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
Wouldn't it break chained assertion errors?
An Error is unrecoverable anyway, if such a case arises it can
always just abort the program immediately.
I think all
On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
Of course, then you'll find the fun of all the tests (and probably code)
that catch AssertError.
You can catch AssertError. There's no guarantees dtors have been called
during unwinding. -- Andrei
On 12.12.2016 22:35, Brad Roberts via Digitalmars-d wrote:
On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote:
On 12/12/2016 11:35 AM, safety0ff wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
But of course there are many situations out there.
On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote:
On 12/12/2016 11:35 AM, safety0ff wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
But of course there are many situations out there.
Wouldn't it break chained assertion errors?
Once a type in
On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
On 12/12/16 17:51, Andrei Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons - multiple objects in that hierarchy
arguably
On 12/12/2016 12:43 PM, Guillaume Boucher wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
I think all Errors should be singletons - multiple objects in that
hierarchy arguably make no sense.
With that logic, why does Throwable have the field "next"?
Probably
On 12/12/2016 11:35 AM, safety0ff wrote:
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
But of course there are many situations out there.
Wouldn't it break chained assertion errors?
Once a type in Error's cone gets thrown there is no guarantee of
unwinding, hence
On 12/12/16 17:51, Andrei Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons - multiple objects in that hierarchy
arguably make no sense. But of course there are many
On 12/12/16 17:51, Andrei Alexandrescu wrote:
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons - multiple objects in that hierarchy
arguably make no sense. But of course there are many
On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
Wouldn't it break chained assertion errors?
An Error is unrecoverable anyway, if such a case arises it can
always just abort the program immediately.
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu
wrote:
I think all Errors should be singletons - multiple objects in
that hierarchy arguably make no sense.
With that logic, why does Throwable have the field "next"?
On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu
wrote:
But of course there are many situations out there.
Wouldn't it break chained assertion errors?
Here it is:
https://github.com/dlang/druntime/pull/1710
It relieves code that uses assert from needing the GC. I think all
Errors should be singletons - multiple objects in that hierarchy
arguably make no sense. But of course there are many situations out
there. If this breaks your code,
38 matches
Mail list logo
