I want to start by stating that the discussion around being able
to throw Error from nothrow functions and the compiler
optimizations that follow is important to the thoughts below.
The other aspect of array bounds checking is that those
particular checks will not be added in -release. There
On 6/8/17 11:19 AM, Stanislav Blinov wrote:
On Thursday, 8 June 2017 at 14:13:53 UTC, Steven Schveighoffer wrote:
void foo(Mutex m, Data d) pure
{
synchronized(m)
{
// ... manipulate d
} // no guarantee m gets unlocked
}
Isn't synchronized(m) not nothrow?
You're right, it
On Thursday, 8 June 2017 at 14:13:53 UTC, Steven Schveighoffer
wrote:
void foo(Mutex m, Data d) pure
{
synchronized(m)
{
// ... manipulate d
} // no guarantee m gets unlocked
}
-Steve
Isn't synchronized(m) not nothrow?
On 06/08/2017 04:02 PM, Olivier FAURE wrote:
That's true. A "pure after cleanup" function is incompatible with
catching Errors (unless we introduce a "scope(error)" keyword that also
runs on errors, but that comes with other problems).
Is pureMalloc supposed to be representative of pure
On 6/8/17 9:42 AM, Olivier FAURE wrote:
On Thursday, 8 June 2017 at 12:20:19 UTC, Steven Schveighoffer wrote:
Hm... if you locked an object that was passed in on the stack, for
instance, there is no guarantee the object gets unlocked.
This wouldn't be allowed unless the object was duplicated
On Thursday, 8 June 2017 at 13:02:38 UTC, ag0aep6g wrote:
Catching the resulting error is @safe when you throw the int*
away. So if f is `pure` and you make sure that the arguments
don't survive the `try` block, you're good, because f
supposedly cannot have reached anything else. This is your
On Thursday, 8 June 2017 at 12:20:19 UTC, Steven Schveighoffer
wrote:
Hm... if you locked an object that was passed in on the stack,
for instance, there is no guarantee the object gets unlocked.
This wouldn't be allowed unless the object was duplicated /
created inside the try block.
On 06/08/2017 11:27 AM, Olivier FAURE wrote:
Contracts are made to preempt memory corruption, and to protect against
*programming* errors; they're not recoverable because breaking a
contract means that from now on the program is in a state that wasn't
anticipated by the programmer.
Which
On 6/7/17 12:20 PM, Olivier FAURE wrote:
On Monday, 5 June 2017 at 14:05:27 UTC, Steven Schveighoffer wrote:
I don't think this will work. Only throwing Error makes a function
nothrow. A nothrow function may not properly clean up the stack while
unwinding. Not because the stack unwinding code
On Wednesday, 7 June 2017 at 19:45:05 UTC, ag0aep6g wrote:
You gave the argument against catching out-of-bounds errors as:
"it means an invariant is broken, which means the code
surrounding it probably makes invalid assumptions and shouldn't
be trusted."
That line of reasoning applies to
On 06/07/2017 09:45 PM, ag0aep6g wrote:
When no @trusted code is involved, then catching an out-of-bounds error
from a @safe function is safe. No additional rules are needed. Assuming
no compiler bugs, a @safe function simply cannot corrupt memory without
calling @trusted code.
Thinking a
On 06/07/2017 05:19 PM, Olivier FAURE wrote:
How does `@trusted` fit into this? The premise is that there's a bug
somewhere. You can't assume that the bug is in a `@system` function.
It can just as well be in a `@trusted` one. And then `@safe` and
`pure` mean nothing.
I think I mistyped
On Monday, 5 June 2017 at 14:05:27 UTC, Steven Schveighoffer
wrote:
I don't think this will work. Only throwing Error makes a
function nothrow. A nothrow function may not properly clean up
the stack while unwinding. Not because the stack unwinding code
skips over it, but because the compiler
On Wednesday, 7 June 2017 at 15:35:56 UTC, Olivier FAURE wrote:
On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:
Anyway, I don't think this would happen. Most forms of memory
allocations are impure,
Not how pure is currently defined in D, see the referred spec;
allocating
On Monday, 5 June 2017 at 13:13:01 UTC, ketmar wrote:
this still nullifies the sense of Error/Exception differences.
not all errors are recoverable, even in @safe code.
...
using wrappers and carefully checking preconditions looks
better to me. after all, if programmer failed to check some
On Monday, 5 June 2017 at 12:59:11 UTC, Moritz Maxeiner wrote:
On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:
Another problem is that non-gc memory allocated in the try
block would be irreversibly leaked when an Error is thrown
(though now that I think about it, that would
On Monday, 5 June 2017 at 12:51:16 UTC, ag0aep6g wrote:
On 06/05/2017 11:50 AM, Olivier FAURE wrote:
In other words, @safe functions would be allowed to catch
Error after try blocks if the block only mutates data declared
inside of it; the code would look like:
import vibe.d;
//
On 6/5/17 5:50 AM, Olivier FAURE wrote:
I recently skimmed the "Bad array indexing is considered deadly" thread,
which discusses the "array OOB throws Error, which throws the whole
program away" problem.
[snip]
My proposal for solving these problems would be to explicitly allow to
catch
Olivier FAURE wrote:
On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:
tbh, i think that it adds Yet Another Exception Rule to the language,
and this does no good in the long run. "oh, you generally cannot do
that, except if today is Friday, it is rainy, and you've seen pink
unicorn at
On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:
On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:
Pragmatic question: How much work do you think this will
require?
Another problem is that non-gc memory allocated in the try
block would be irreversibly leaked when
On 06/05/2017 11:50 AM, Olivier FAURE wrote:
- But memory corruption is super bad, if a proved error *might* be
caused by memory corruption then we must absolutely throw the
potentially corrupted data away without using it.
- Besides, even without memory corruption, the same argument applies
On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:
Pragmatic question: How much work do you think this will
require?
Good question. I'm no compiler programmer, so I'm not sure what
the answer is.
I would say "probably a few days at most". The change is fairly
self-contained,
On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:
tbh, i think that it adds Yet Another Exception Rule to the
language, and this does no good in the long run. "oh, you
generally cannot do that, except if today is Friday, it is
rainy, and you've seen pink unicorn at the morning." the more
On Monday, 5 June 2017 at 09:50:15 UTC, Olivier FAURE wrote:
My proposal for solving these problems would be to explicitly
allow to catch Errors in @safe code IF the try block from which
the Error is caught is perfectly pure.
This would allow to design applications that can fail
gracefully
Olivier FAURE wrote:
What do you think? Does the idea have merit? Should I make it into a DIP?
tbh, i think that it adds Yet Another Exception Rule to the language, and
this does no good in the long run. "oh, you generally cannot do that,
except if today is Friday, it is rainy, and you've
I recently skimmed the "Bad array indexing is considered deadly"
thread, which discusses the "array OOB throws Error, which throws
the whole program away" problem.
The gist of the debate is:
- Array OOB is a programming problem; it means an invariant is
broken, which means the code
26 matches
Mail list logo
