On 2/9/15 10:13 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Monday, 9 February 2015 at 14:40:36 UTC, Steven Schveighoffer wrote:
On 2/7/15 7:11 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
You are trying to do this:
1. mechanically
On Monday, 9 February 2015 at 14:40:36 UTC, Steven Schveighoffer
wrote:
On 2/7/15 7:11 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
You are trying to do this:
1. mechanically verify the whole @trusted region
2. manually verify the whole @trusted
On 2/6/15 7:29 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Feb 06, 2015 at 04:04:48PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
I agree with Andrei in that I do not believe that reviewing a @trusted
function, line by line, for safety is necessarily some sort of
maintenance
On 2/6/15 4:48 PM, Walter Bright wrote:
On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
This is precisely why I have lost all interest in @safe. It's clear that
the present problematic situation will continue to hold, and the
decision makers are not interested to address it. I am not
On Monday, 9 February 2015 at 14:40:36 UTC, Steven Schveighoffer
wrote:
But we also must tag potential points of leakage with @system.
In fact, it probably could be a warning/error if you have a
@trusted function without any @system escapes (it could just be
marked @safe).
Think of it this
On 2/7/15 7:11 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
You are trying to do this:
1. mechanically verify the whole @trusted region
2. manually verify the whole @trusted region, but be sloppy about it
here an there
3. Ooops, we were sloppy in the
On Saturday, 7 February 2015 at 00:31:41 UTC, H. S. Teoh wrote:
This does not take into the account the fact that a @trusted
function
may call other, non-@trusted, functions. When one of those other
functions changes, the @trusted function necessarily needs to be
reviewed again.
However, under
On 2/6/15 8:43 PM, Andrei Alexandrescu wrote:
On 2/6/15 3:21 PM, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have confirmed
that we've moved beyond requesting @trusted blocks. We are no longer
On Saturday, 7 February 2015 at 11:32:41 UTC, Steven
Schveighoffer wrote:
The idea is that @trusted code still has to be reviewed for
memory issues, but is mechanically checked for most of the
function for obvious @safe violations. It limits to a degree
the scrutiny one must apply to the
On 2/6/15 4:36 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
In the proposal, @trusted code is actually considered the same as
@safe, but allows @system escapes.
But that can't work:
On 2/6/15 5:19 PM, Meta wrote:
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
In the proposal, @trusted code is actually considered the same as
@safe, but allows @system escapes.
That seems like a good idea and in the spirit of what the goal is.
However, won't it be a
On Saturday, 7 February 2015 at 06:20:16 UTC, Walter Bright wrote:
On 2/6/2015 9:49 PM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright
wrote:
1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
On 2/6/2015 3:02 PM, Zach the Mystic wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code
can generate; it catches unintended safety violations in all
@trusted code
outside @system blocks, as
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
The solution is to regard @trusted as a means of encapsulating
unsafe operations, not escaping them. Encapsulating them means
that the interface from the @trusted code is such that it is
usable from safe code without having to
On Saturday, 7 February 2015 at 10:02:23 UTC, ponce wrote:
If I understand correctly, your rule o be a trusted function is:
Unable to create a memory corrutpion whatever the arguments.
But here:
- dest or src could be the null slice
- the assert would go away in release
So I though this
On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu
wrote:
I think the problem is overstated. -- Andrei
I think there could hardly be a more persuasive argument that
this belief is wrong than Walter himself just having made the
mistake several times, and not even immediately
On Saturday, 7 February 2015 at 12:40:26 UTC, David Nadlinger
wrote:
Neither of those issues would have been prevented by your new
guidelines; the code in question is already written in that
way. Quite to the contrary, consequent application of minimal
@trusted blocks or even the workaround
On 2/7/15 4:40 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:52:45 UTC, Andrei Alexandrescu wrote:
I think the problem is overstated. -- Andrei
I think there could hardly be a more persuasive argument that this
belief is wrong than Walter himself just having made the mistake
https://github.com/klickverbot/phobos/commit/db647f62cb5279ae42ad98665cd60cdcdb9b3dd5
Nice, thanks for this work. One good guideline here is to
almost always let generic code rely on deduction instead of
ascribing safety attributes to it.
Andrei
And making this work in functions that
And I'll add this:
Please do not turn the compiler into a inadequate verification
tool. The compiler should do what it can do well, but what it
cannot do it should not do at all and leave to an external
verification tool.
@trusted basically tells the compiler this is beyond your
capability
On Friday, 6 February 2015 at 23:21:50 UTC, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic
wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are
On 2/6/15 11:29 AM, Zach the Mystic wrote:
The best evidence I have it that everyone who actually worked on the
phobos code you disapprove of says it's a problem.
I see more like two. -- Andrei
On Friday, 6 February 2015 at 17:50:05 UTC, Tobias Pankrath wrote:
I was referring to a hypothetical untrusted block that might
be used something like this:
---
void foo(Range)(Range r) @trusted {
// ...
untrusted {
r.front;
}
// Your manually checked code.
untrusted {
On 2/6/2015 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted blocks (trusted
{...}) into @safe functions. But what about having safe blocks in @trusted
functions ?
int somefunc() @trusted
{
int a = systemfunc();
int b;
@safe {
b
On 2/6/15 12:36 PM, Atila Neves wrote:
I'm trying to promote suggesting '@system' blocks instead of
'@trusted'. '@trusted' functions, but '@system' blocks - which can
only go in @trusted functions (@system block in @system functions are
redundant). It's the same semantics, but it might win the
On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic wrote:
It's been suggested that '@system' be used to mark the blocks
in question. The point would be to emphasize the dangerousness
of the operation. The function is still @trusted, but inside,
the @system code is marked as such.
On 2/6/15 2:16 PM, Andrei Alexandrescu wrote:
On 2/6/15 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:
On 2/6/15 10:42 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:39:28 UTC, Andrei
On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/6/15 10:42 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote:
It's clear. I just don't think it's a good point. -- Andrei
I'm not making a point; I'm
On 2/6/15 3:02 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer wrote:
I see the point now that making sure @safe functions don't have
escapes has the advantage of not requiring *as much* review
On 2/6/2015 4:17 AM, Kagamin wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length ==
On Friday, 6 February 2015 at 18:58:27 UTC, David Nadlinger wrote:
On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic
wrote:
It's been suggested that '@system' be used to mark the blocks
in question. The point would be to emphasize the dangerousness
of the operation. The function is
On 2/6/15 11:53 AM, Steven Schveighoffer wrote:
I think your strawman is overstated. The doomsday is the current
situation to which you and Walter have objected.
I see that just as: code in poor style made its way in Phobos. It
doesn't improve anything (e.g. didn't find bugs in
On 2/6/2015 5:13 AM, Vladimir Panteleev wrote:
So, to repeat my question: which one is it? Have you changed your mind, or are
there exceptions to the rules in the post you quoted?
It means that you, the programmer, have to decide whether it is environmental
input validation or a logic error
On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote:
It seems obvious that explicitly whitelisting a small number of
potentially dangerous but safe operations is much less
error-prone approach than disabling compiler checks for
everything and then having to remember to blacklist
On 2/6/15 10:36 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 15:10:18 UTC, Steven Schveighoffer wrote:
into suspect the whole function. So marking a function @safe, and
having it mean this function has NO TRUSTED OR SYSTEM
On 2/6/15 10:42 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote:
It's clear. I just don't think it's a good point. -- Andrei
I'm not making a point; I'm posing a problem. What is your solution?
I think the problem is overstated. -- Andrei
On 2/6/15 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/6/15 10:42 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote:
It's clear. I just don't think it's
On Friday, 6 February 2015 at 19:16:13 UTC, Andrei Alexandrescu
wrote:
This is precisely why I have lost all interest in @safe. It's
clear that
the present problematic situation will continue to hold, and
the
decision makers are not interested to address it. I am not
going to
waste any more
On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer
wrote:
My point was that if you have @trusted escapes inside a
function, whether it's marked @safe or not, you still have to
review the whole function. If the compiler disallowed this
outright, then you don't have that issue.
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer
wrote:
In the proposal, @trusted code is actually considered the same
as @safe, but allows @system escapes.
But that can't work:
@trusted_is_safe {
auto tmp = get_hardware_config();
@system{
mess_up_hardware_config();
On 2/6/2015 7:48 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Then how is this more work than implementing something like a linear type system
that is both tedious for the programmer and has taken Rust 8 years to get into
working shape...?
Rust has unsafe
On 2/6/2015 7:14 AM, Wyatt wrote:
The current @trusted semantics (and accompanying politics) make it exceedingly
clear that @safe is meaningless for anything beyond trivial, one-off tools that
will never receive maintenance.
You are correct in how @trusted is currently (mis)used in Phobos. We
On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
This is precisely why I have lost all interest in @safe. It's clear that
the present problematic situation will continue to hold, and the
decision makers are not interested to address it. I am not going to
waste any more time and energy
On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote:
Rust has unsafe blocks with specific instructions that it
cannot be verified mechanically and it is up to the programmer
to ensure a safe interface to it.
So no, Rust didn't get that working, either, and it is far
beyond
On 2/6/2015 2:39 PM, Meta wrote:
On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote:
Rust has unsafe blocks with specific instructions that it cannot be verified
mechanically and it is up to the programmer to ensure a safe interface to it.
So no, Rust didn't get that working,
On 2/6/2015 3:02 PM, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've
moved beyond requesting @trusted blocks. We are no longer requesting them. We
are requesting *@system* blocks, which can only appear in @trusted and @system
functions. Any
On 2/6/2015 10:58 AM, David Nadlinger wrote:
@trusted doesn't differ in meaning from @safe for API clients. Both mean that
you can call the function from @safe code, nothing more, nothing less. I hope we
agree on that.
That is correct. @trusted is a statement about the implementation of a
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are requesting *@system*
blocks, which can only appear in @trusted
On Friday, 6 February 2015 at 21:56:40 UTC, Walter Bright wrote:
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just
thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this
On 2/6/2015 8:19 AM, John Colvin wrote:
Is that what we want? I can't see why not, but it feels off somehow...
Effectively you've got @trusted blocks in an @trusted function, just inverted.
Right. It just inverted the interface problem, the problem remains. So, no for
this idea.
Another way
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this question.
You asked:
Why not force the programmer to tag precisely
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer
wrote:
In the proposal, @trusted code is actually considered the same
as @safe, but allows @system escapes.
That seems like a good idea and in the spirit of what the goal
is. However, won't it be a breaking change?
On 2/6/2015 5:28 AM, Steven Schveighoffer wrote:
It's better because I know where it is used. It's used in one place, and I can
squash it right there saying No, you can't do this in this one place. Instead
of reviewing an API in ALL POSSBILE CONTEXTS (which if trustedCast is a public
API, would
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code can generate; it catches unintended safety
violations in all @trusted code outside @system blocks, as
requested by many people so far; it makes
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
I suspect that such a feature would simply lull people into a
false sense of security in that merely tagging an unsafe cast
with @system and the compiler accepting it is good enough.
My evidence for this is how @trusted was used
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code
can generate; it catches unintended safety violations in all
@trusted code
outside @system blocks, as requested by many people so far; it
makes systems
On Saturday, 7 February 2015 at 01:43:01 UTC, Andrei Alexandrescu
wrote:
With the system proposal we're looking at something like:
version (Posix) void[] read(in char[] name, size_t upTo =
size_t.max) @trusted
{
import core.memory;
// A few internal configuration parameters {
enum
On 2/6/2015 9:49 PM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright wrote:
1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs in your program
OK, this is nothing new, but still doesn't answer
On Saturday, 7 February 2015 at 01:41:19 UTC, Andrei Alexandrescu
wrote:
Consider the previous code:
[...]
static trustedRead(int fildes, void* buf, size_t nbyte)
@trusted
{
return core.sys.posix.unistd.read(fildes, buf, nbyte);
}
static trustedRealloc(void* p, size_t
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic
wrote:
Note that I just mechanically your @system blocks with the
better form.
...mechanically replaced, I mean, of course.
On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright wrote:
1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs in your
program
OK, this is nothing new, but still doesn't answer my question.
Would you say that the correct
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic
wrote:
Here's how I would rewrite what you have written using the new
method:
...
stat_t statbuf = void;
@system cenforce(trustedFstat(fd, trustedRef(statbuf)) ==
0, name);
I didn't rewrite this because I didn't see the
On Friday, 6 February 2015 at 21:33:01 UTC, Walter Bright wrote:
On 2/6/2015 10:58 AM, David Nadlinger wrote:
@trusted doesn't differ in meaning from @safe for API clients.
Both mean that
you can call the function from @safe code, nothing more,
nothing less. I hope we
agree on that.
That is
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are requesting *@system*
blocks, which can only appear in @trusted
On 2/6/2015 3:34 PM, David Nadlinger wrote:
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
I suspect that such a feature would simply lull people into a false sense of
security in that merely tagging an unsafe cast with @system and the compiler
accepting it is good enough.
My
On Fri, Feb 06, 2015 at 04:04:48PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
I agree with Andrei in that I do not believe that reviewing a @trusted
function, line by line, for safety is necessarily some sort of
maintenance nightmare. If it is, then a refactoring should be
considered
On 2/6/2015 4:29 PM, H. S. Teoh via Digitalmars-d wrote:
This does not take into the account the fact that a @trusted function
may call other, non-@trusted, functions. When one of those other
functions changes, the @trusted function necessarily needs to be
reviewed again.
That's correct.
On 2/6/15 3:21 PM, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have confirmed
that we've moved beyond requesting @trusted blocks. We are no longer
requesting them. We are requesting *@system* blocks,
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
}
Should be enforce: assert
On Friday, 6 February 2015 at 05:32:48 UTC, Walter Bright wrote:
Good point. Then a constraint can be added to the function
signature that T is copyable.
D's type system is strong enough for that.
Yes, if you remember to add it. The ideal would be to have the
default constrained to proper
On Friday, 6 February 2015 at 10:28:38 UTC, Walter Bright wrote:
On 2/6/2015 1:01 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright
wrote:
Cue my endless attempts to explain the difference between
input errors and
logic errors :-(
So which one is it?
If I understand it correctly, Walter is against adding trusted
blocks (trusted {...}) into @safe functions. But what about
having safe blocks in @trusted functions ?
int somefunc() @trusted
{
int a = systemfunc();
int b;
@safe {
b = safefunc(); // calling systemfunc() not
This prevents that a @trusted/@safe function becoming @system
breaks the @trusted guarantee of called functions.
Calling function, forward in the example.
On 2/6/2015 1:01 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
Cue my endless attempts to explain the difference between input errors and
logic errors :-(
So which one is it?
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright
wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr,
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright
wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr,
FWIW, and now that I think I understand how @trusted is supposed
to be used, the arguments are valid. But I also:
1. Agree with H S Teoh on the maintainability aspect. Depending
on humans reviewing the code is never going to work out. And even
if it did, subsequent edits might break
On Friday, 6 February 2015 at 14:00:24 UTC, Atila Neves wrote:
1. Agree with H S Teoh on the maintainability aspect. Depending
on humans reviewing the code is never going to work out.
Of course it can work out. You need a formalized process and a
group of people with training in math or
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
}
Should be enforce: assert doesn't guard against malicious usage.
On Friday, 6 February 2015 at 15:14:14 UTC, Wyatt wrote:
On Friday, 6 February 2015 at 13:42:40 UTC, Ola Fosheim Grøstad
wrote:
cannot modify this without detailed review.
This quote from Ola, here? That basically describes my job
maintaining big piles of legacy C: the compiler verifies
On Friday, 6 February 2015 at 15:14:14 UTC, Wyatt wrote:
So from my perspective, calling this situation completely
impractical reveals a stunning gift for understatement. Is
this really the best we can do after however many years?
Because it blows.
The current @trusted semantics (and
Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer wrote:
The bottom line of my reasoning is that code changes over time, by
different people. Context is forgotten. It's much better to have the
compiler verify you
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted blocks
(trusted {...}) into @safe functions. But what about having safe blocks
in @trusted functions ?
That would be sensible - perhaps the best step forward following this
long
On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted
blocks
(trusted {...}) into @safe functions. But what about having
safe blocks
in @trusted functions ?
That would
On 2/6/15 5:13 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 10:28:38 UTC, Walter Bright wrote:
On 2/6/2015 1:01 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
Cue my endless attempts to explain the difference between input
errors
On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted
blocks
(trusted {...}) into @safe functions. But what about having
safe blocks
in @trusted functions ?
That would
On Friday, 6 February 2015 at 17:02:44 UTC, Wyatt wrote:
On Friday, 6 February 2015 at 15:48:45 UTC, Ola Fosheim Grøstad
wrote:
2. @trusted sections are written without dependencies
This really won't happen unless statically enforced because
humans are involved.
3. @trusted are formally
On Friday, 6 February 2015 at 16:50:51 UTC, Tobias Pankrath wrote:
On Friday, 6 February 2015 at 16:40:10 UTC, David Nadlinger
wrote:
This still does not solve the template inference problem
though, unless you make it a non-@trusted block instead of
requiring @safe-ty.
Don't understand. If
On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding
trusted blocks
(trusted {...}) into @safe functions. But what
On 2/6/15 9:07 AM, Tobias Pankrath wrote:
At least I expect the amount of @trusted in phobos to be much higher
than in normal user code.
Exactly. There's a bunch of low-level interfaces in Phobos and also some
code that aims at maximum efficiency.
Andrei
On 2/6/15 8:40 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu wrote:
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted blocks
(trusted {...}) into @safe functions. But what about having safe
On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote:
Let's say you have a template function that accepts a range.
For performance, you want to do some of the processing in a way
that is @system, but can be verified to be correct for all
inputs in this specific case. In other
On Friday, 6 February 2015 at 10:28:38 UTC, Walter Bright wrote:
On 2/6/2015 1:01 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright
wrote:
Cue my endless attempts to explain the difference between
input errors and
logic errors :-(
So which one is it?
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright
wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr,
First, I want to say that I didn't want to cause a huge rift between D
developers with this, I didn't think this was such a drastic issue, just
a possible idea. But here we are. I hope we can mend this, and move
forward. But on to the discussion.
On 2/5/15 6:39 PM, Walter Bright wrote:
On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer
wrote:
The bottom line of my reasoning is that code changes over time,
by different people. Context is forgotten. It's much better to
have the compiler verify you know what you are doing when
working with @trusted than it is to
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright
wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr,
6. @trusted code should be self contained so that changes in
called functions don't break the proof...
On 2/6/15 8:42 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer wrote:
The bottom line of my reasoning is that code changes over time, by
different people. Context is forgotten. It's much better
On Friday, 6 February 2015 at 13:42:40 UTC, Ola Fosheim Grøstad
wrote:
cannot modify this without detailed review.
This quote from Ola, here? That basically describes my job
maintaining big piles of legacy C: the compiler verifies nothing,
so every change to the anything in the API of safe
1 - 100 of 144 matches
Mail list logo
