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 CODE
in it whatsoever, is probably the right move, regardless of any
other changes.
But that would
On Friday, 6 February 2015 at 17:02:44 UTC, Wyatt wrote:
3. @trusted are formally proven safe
...by humans?
It isn't that hard for typical library code that is required to
be non-safe.
You don't have to do better than the compiler code in terms of
probability of slipping things
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 {
r.popFront;
}
// …
}
---
Using current semantics we must not
On Friday, 6 February 2015 at 17:16:19 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 8:40 AM, David Nadlinger wrote:
This still does not solve the template inference problem
What is that?
See my reply to Tobias [1]. This seems to be the crux of our
disagreement and/or misunderstanding, and is
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 day because the intent is to isolate
On Friday, 6 February 2015 at 16:19:00 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 5:13 AM, Vladimir Panteleev wrote:
That doesn't answer my question.
A few years ago, I recall, you were arguing that for functions
which are
or may be exported to a DLL, thus all Phobos functions, it is
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 that matters, the code shouldn't be marked
@trusted
in the first
On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
I can instantly see this happening:
void foo() @trusted
{
auto p = malloc(…)
@safe
{
global_datastructure.push(p)
//loads of code
}
free(p)
//a few lines of system code,
On 2/6/15 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.
That's the natural direction - the default assumption is weak, and you
have the option to temporarily
On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
It feels inelegant, but it might be the best way out of a bad
situation.
I can instantly see this happening:
void foo() @trusted
{
@safe
{
//loads of code
}
//a few lines of system code, only safe due to
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 proven safe
...by humans?
4. @trusted functions rarely
On Friday, 6 February 2015 at 17:36:27 UTC, 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
On Friday, 6 February 2015 at 18:30:03 UTC, Zach the Mystic wrote:
That might be better than using @safe inside @trusted:
@trusted void myfunc() {
//implicitly safe
...
@system { //wouldn't compile otherwise.
auto ptr = cast(ubyte*)4;
}
//implicitly safe again
}
Exactly. I think this
On 2/6/15 9:28 AM, David Nadlinger wrote:
On Friday, 6 February 2015 at 17:16:19 UTC, Andrei Alexandrescu wrote:
On 2/6/15 8:40 AM, David Nadlinger wrote:
This still does not solve the template inference problem
What is that?
See my reply to Tobias [1]. This seems to be the crux of our
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?
David
On 2/6/15 9:41 AM, Vladimir Panteleev wrote:
On Friday, 6 February 2015 at 16:19:00 UTC, Andrei Alexandrescu wrote:
On 2/6/15 5:13 AM, Vladimir Panteleev wrote:
That doesn't answer my question.
A few years ago, I recall, you were arguing that for functions which are
or may be exported to a
I figured that someone would have already objected to part of this, but
the definition is stronger than I believe is intended for D:
On 2/5/2015 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
2) I think we also all basically agree that the *intent* of @trusted is
to be an encapsulation
On 2/5/2015 8:30 PM, Brad Roberts via Digitalmars-d wrote:
@safe code is memory safe when passed good inputs. @safe code does not have to
detect or prevent garbage input from causing harm. The promises of @trusted
aren't stronger than that either.
This is correct. Thanks for catching it.
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);
}
I don't have to review callers of trustedMemory() because it
On 2/5/2015 8:20 PM, Dicebot wrote:
I am not even sure how you can show the example though, to be honest - implied
issues are about maintaining code and not just writing it.
Let's start with std.array.uninitializedArray():
auto uninitializedArray(T, I...)(I sizes) nothrow @trusted
Note
On 2/5/2015 9:00 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com 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,
On Friday, 6 February 2015 at 05:32:48 UTC, Walter Bright wrote:
On 2/5/2015 9:00 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright
wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
On Friday, 6 February 2015 at 03:14:59 UTC, Walter Bright wrote:
I don't see how any proposal can work unless it specifies a
safe interface to an unsafe section of code. (I read a Rust
tutorial that rather bluntly pointed this out as well.)
Link?
On Friday, 6 February 2015 at 01:12:18 UTC, Walter Bright wrote:
On 2/5/2015 4:13 PM, Dicebot wrote:
I know this definition. It have tried it in practice and
concluded as being
absolutely useless. There is no way I am going to return back
to this broken
concept - better to ignore @safe
On 2/5/2015 7:39 PM, Zach the Mystic wrote:
On Friday, 6 February 2015 at 03:14:59 UTC, Walter Bright wrote:
I don't see how any proposal can work unless it specifies a safe interface to
an unsafe section of code. (I read a Rust tutorial that rather bluntly pointed
this out as well.)
Link?
On 2/5/2015 9:55 PM, weaselcat wrote:
What's the D way of checking if a parameter is a reftype, valuetype, etc?
http://dlang.org/phobos/std_traits.html
On 2/5/15 3:43 PM, Dicebot wrote:
The fact that @trusted is contained in small block doesn't mean rest of
@safe function doesn't need to be reviewed. Only difference is review
all manually vs review all manually with some help of compiler.
As Steve and others have shown, unsafe code under the
On 2/5/2015 3:43 PM, Dicebot wrote:
The fact that @trusted is contained in small block doesn't mean rest of @safe
function doesn't need to be reviewed. Only difference is review all manually
vs review all manually with some help of compiler.
I did a review of all uses of @trusted in std.array:
On Friday, 6 February 2015 at 00:04:26 UTC, Walter Bright wrote:
On 2/5/2015 3:43 PM, Dicebot wrote:
The fact that @trusted is contained in small block doesn't
mean rest of @safe
function doesn't need to be reviewed. Only difference is
review all manually
vs review all manually with some help
On Thursday, 5 February 2015 at 23:49:05 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 3:43 PM, Dicebot wrote:
The fact that @trusted is contained in small block doesn't
mean rest of
@safe function doesn't need to be reviewed. Only difference is
review
all manually vs review all manually with some
Consider the following code excerpted from std.array.join:
static U trustedCast(U, V)(V v) @trusted { return cast(U) v; }
return trustedCast!RetType(result);
This is because the compiler would complain that the following line would not be
@safe:
return cast(RetType)(result);
The
The fact that @trusted is contained in small block doesn't mean
rest of @safe function doesn't need to be reviewed. Only
difference is review all manually vs review all manually with
some help of compiler.
On Thursday, 5 February 2015 at 23:43:19 UTC, Dicebot wrote:
The fact that @trusted is contained in small block doesn't mean
rest of @safe function doesn't need to be reviewed. Only
difference is review all manually vs review all manually
with some help of compiler.
I believe that was also
On 2/5/2015 4:13 PM, Dicebot wrote:
I know this definition. It have tried it in practice and concluded as being
absolutely useless. There is no way I am going to return back to this broken
concept - better to ignore @safe completely as misfeature if you insist on doing
things that way.
I'm
On 2/5/15 5:12 PM, Walter Bright wrote:
On 2/5/2015 4:13 PM, Dicebot wrote:
I know this definition. It have tried it in practice and concluded as
being
absolutely useless. There is no way I am going to return back to this
broken
concept - better to ignore @safe completely as misfeature if you
On Thu, Feb 05, 2015 at 11:50:05PM +, Dicebot via Digitalmars-d wrote:
On Thursday, 5 February 2015 at 23:43:19 UTC, Dicebot wrote:
The fact that @trusted is contained in small block doesn't mean rest
of @safe function doesn't need to be reviewed. Only difference is
review all manually vs
On 2/5/15 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
It is a desperate attempt to contain a
maintenance problem that's growing out of hand.
Before we get into this - do you have evidence of the maintenance
problem that's growing out of hand? E.g. bugs in std.file that were
fixed etc.
On Thu, Feb 05, 2015 at 05:12:16PM -0800, Walter Bright via Digitalmars-d wrote:
On 2/5/2015 4:13 PM, Dicebot wrote:
I know this definition. It have tried it in practice and concluded as
being absolutely useless. There is no way I am going to return back
to this broken concept - better to
On 2/5/15 5:53 PM, H. S. Teoh via Digitalmars-d wrote:
And while
you're at it, try reviewing a few Phobos PR's related to std.array as
well, and observe for yourself the maintenance issues that arise.
Again, could you please collect past evidence of such? According to you
there must be many
On Friday, 6 February 2015 at 02:06:29 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 5:53 PM, H. S. Teoh via Digitalmars-d wrote:
And while
you're at it, try reviewing a few Phobos PR's related to
std.array as
well, and observe for yourself the maintenance issues that
arise.
Again, could you
On 2/5/15 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
This whole discussion has been very tiring and frustrating, because we
keep talking past each other. The reason we keep talking past each other
is because we keep conflating several distinct, though related, issues.
Bummer about that.
On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
(2) I don't think the proposal you sketched at http://goo.gl/JWqafx is good.
The goo link is disabled for violating goo's terms of service, whatever that
means.
What's the real url?
On 2/5/15 6:52 PM, Walter Bright wrote:
On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
(2) I don't think the proposal you sketched at http://goo.gl/JWqafx is
good.
The goo link is disabled for violating goo's terms of service, whatever
that means.
What's the real url?
On 2/5/2015 7:00 PM, Andrei Alexandrescu wrote:
On 2/5/15 6:52 PM, Walter Bright wrote:
On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
(2) I don't think the proposal you sketched at http://goo.gl/JWqafx is
good.
The goo link is disabled for violating goo's terms of service, whatever
that
101 - 144 of 144 matches
Mail list logo
