On Tuesday, 10 February 2015 at 15:57:28 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
As already pointed out in the other thread, there is a
non-breaking variant of (3):
3a. Keep named @trusted functions, allow @system blocks
inside them,
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
Wait a second... you're totally right. That is a cool solution.
The only hiccup is that it might be hard to implement in the
compiler because of flow tracking (i.e. the error comes before
the @system block, forcing a recheck
On Tuesday, 10 February 2015 at 16:04:05 UTC, Marc Schütz wrote:
On Tuesday, 10 February 2015 at 15:57:28 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
As already pointed out in the other thread, there is a
non-breaking variant of (3):
3a.
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to
save people
the awkward burden of importing it from std.conv all the time.
But that
would be a language change, of
On 2/9/2015 11:27 PM, Dicebot wrote:
As you may see in generated call it actually calls lambda function
(_D4test4mainFNfZ9__lambda1FNeZv) instead of calling _D4test3fooFZv directly
https://issues.dlang.org/show_bug.cgi?id=14164
On 2/9/2015 9:04 PM, Steven Schveighoffer wrote:
This is not an issue that should dictate convention, non-inlined code does not
impact correctness, only performance. And once it is fixed in the compiler, the
argument would be gone, and we would be left with a convention with no good
reason.
On Tuesday, 10 February 2015 at 15:47:14 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 12:27:29 UTC, Marc Schütz wrote:
On Tuesday, 10 February 2015 at 06:35:08 UTC, Zach the Mystic
wrote:
I never used the named @trusted function for its original
purpose anyway. I dont' see it as
On Tuesday, 10 February 2015 at 12:27:29 UTC, Marc Schütz wrote:
On Tuesday, 10 February 2015 at 06:35:08 UTC, Zach the Mystic
wrote:
I never used the named @trusted function for its original
purpose anyway. I dont' see it as a big sacrifice, but anyway,
you have three choices:
1. Keep
On 2/10/15 9:06 AM, Russel Winder via Digitalmars-d wrote:
On Mon, 2015-02-09 at 13:12 -0500, Steven Schveighoffer via Digitalmars-d wrote:
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
As already pointed out in the other thread, there is a
non-breaking variant of (3):
3a. Keep named @trusted functions, allow @system blocks
inside them, but only treat those with @system blocks with
the new semantics.
But
On Tuesday, 10 February 2015 at 06:35:08 UTC, Zach the Mystic
wrote:
I never used the named @trusted function for its original
purpose anyway. I dont' see it as a big sacrifice, but anyway,
you have three choices:
1. Keep *named* @trusted functions for their original purpose,
continue to
On Mon, 2015-02-09 at 13:12 -0500, Steven Schveighoffer via Digitalmars-d wrote:
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm okay with this as with most of Steve's points. But
string toUpper(string s) @safe
{
char[] r = new char[s.length];
foreach (i, c; s)
r[i] = toUpper(c);
return cast(string)r; // == unsafe operation
}
Shouldn't that be `return assumeUnique(r)` instead?
What about requiring to put in-code comment that mentions
On Tuesday, 10 February 2015 at 05:18:26 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 9:06 PM, Dicebot wrote:
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei
Alexandrescu wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to
save people
On Mon, Feb 09, 2015 at 12:19:10AM -0800, Walter Bright via Digitalmars-d wrote:
[...]
Trusted Manifesto
-
[...]
RULE 1: @trusted code accessible from @safe code must expose a safe
interface to unsafe operations.
@trusted must not be used to inject unsafety into surrounding
On Tuesday, 10 February 2015 at 03:36:14 UTC, Walter Bright wrote:
On 2/9/2015 6:21 PM, H. S. Teoh via Digitalmars-d wrote:
What stops the following abuse of @trusted via
trusted()?
int* myFunc(void* p) @safe // -- I'm claiming to be @safe
{
// But actually I'm
On 2/9/15 6:21 PM, H. S. Teoh via Digitalmars-d wrote:
I wonder if there's a way, in the current language, to make it illegal
to call trusted() from a function explicitly marked @safe...?
No, but that might be worthy future consideration. I think we now should
move forward with this and see
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to
save people
the awkward burden of importing it from std.conv all the time.
But that
would be a language change, of
On 2/9/2015 6:21 PM, H. S. Teoh via Digitalmars-d wrote:
What stops the following abuse of @trusted via
trusted()?
int* myFunc(void* p) @safe // -- I'm claiming to be @safe
{
// But actually I'm not! Though I can convince the
// compiler that I
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to save people
the awkward burden of importing it from std.conv all the time. But that
would be a language change, of sorts.
We won't define it. Instead we'll go with Steve's idea: () @trusted =
On 2/9/2015 9:06 PM, Dicebot wrote:
This was exactly how all those trustedFoo() nested functions have appeared
- we wanted to localized unsafe operations with `() @trusted {}` but it wasn't
properly inlined by DMD.
DMD will inline trivial functions like that. In what case does it not?
and criticisms of the participants
in the references. It involves no language changes, but offers usage
guidelines that we believe are workable. Tell us what you think!
Trusted Manifesto
-
Memory safety in D has the usual definition
On 2/9/15 1:18 PM, Andrei Alexandrescu wrote:
On 2/9/15 10:12 AM, Steven Schveighoffer wrote:
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm okay with this as with most of Steve's points.
On Monday, 9 February 2015 at 18:18:23 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 10:12 AM, Steven Schveighoffer wrote:
Merriam Webster says otherwise ;)
http://www.merriam-webster.com/dictionary/generic
Interesting, thanks. Also, M-W does not list genericity. --
Webster needs to get over
that we
believe are workable. Tell us what you think!
Trusted Manifesto
-
Memory safety in D has the usual definition: a memory-safe program never reads
uninitialized memory and never reads or writes memory with a type
On Tuesday, 10 February 2015 at 07:02:23 UTC, Walter Bright wrote:
On 2/9/2015 9:06 PM, Dicebot wrote:
This was exactly how all those trustedFoo() nested functions
have appeared
- we wanted to localized unsafe operations with `() @trusted
{}` but it wasn't
properly inlined by DMD.
DMD will
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm okay with this as with most of Steve's points. But genericness is
not a word :o). -- Andrei
Merriam Webster says otherwise ;)
On 2/9/15 2:09 AM, Kagamin wrote:
Also why safe code is allowed to create unsafe lambdas?
Might be interesting to restrict that. -- Andrei
On 2/9/15 2:05 AM, Kagamin wrote:
On Monday, 9 February 2015 at 08:19:24 UTC, Walter Bright wrote:
while not allowing std.conv.trusted escapes in @safe function would be
by convention.
Can SafeD be enforced given that?
At some point you have to define a trusted computing base. That includes
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm okay with this as with most of Steve's points. But genericness is
not a word :o). -- Andrei
On 2/9/15 10:12 AM, Steven Schveighoffer wrote:
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted = cast(immutable)a)();
I'm okay with this as with most of Steve's points. But genericness is
not a word :o). -- Andrei
On Monday, 9 February 2015 at 20:24:02 UTC, Walter Bright wrote:
On 2/9/2015 4:14 AM, Meta wrote:
Yes, but is it disabled by default in @trusted code?
It is never disabled by default.
Okay, I thought it was similar to @system in that respect.
On 2/9/2015 4:14 AM, Meta wrote:
Yes, but is it disabled by default in @trusted code?
It is never disabled by default.
in the references. It
involves no language changes, but offers usage guidelines that
we believe are workable. Tell us what you think!
Trusted Manifesto
-
Memory safety in D has the usual definition: a memory-safe
program never reads
On Monday, 9 February 2015 at 11:47:03 UTC, Meta wrote:
On Monday, 9 February 2015 at 11:43:00 UTC, Walter Bright wrote:
On 2/9/2015 2:54 AM, John Colvin wrote:
It seems to me that rules 2 and 3 could be helped along by
tooling (compiler or
external).
Sounds good, but I'd like to see how
On Monday, 9 February 2015 at 10:16:48 UTC, Walter Bright wrote:
On 2/9/2015 1:36 AM, Dicebot wrote:
string toUpper(string s) @safe
{
char[] r = new char[s.length];
foreach (i, c; s)
r[i] = toUpper(c);
return cast(string)r; // == unsafe operation
}
Shouldn't that be `return
On Monday, 9 February 2015 at 11:43:00 UTC, Walter Bright wrote:
On 2/9/2015 2:54 AM, John Colvin wrote:
It seems to me that rules 2 and 3 could be helped along by
tooling (compiler or
external).
Sounds good, but I'd like to see how this works in practice
before going further with it. The
Also why safe code is allowed to create unsafe lambdas?
On Monday, 9 February 2015 at 08:19:24 UTC, Walter Bright wrote:
while not allowing std.conv.trusted escapes in @safe function
would be by convention.
Can SafeD be enforced given that?
On 2/9/2015 1:36 AM, Dicebot wrote:
string toUpper(string s) @safe
{
char[] r = new char[s.length];
foreach (i, c; s)
r[i] = toUpper(c);
return cast(string)r; // == unsafe operation
}
Shouldn't that be `return assumeUnique(r)` instead?
assumeUnique does a little more
On 2/9/2015 2:54 AM, John Colvin wrote:
It seems to me that rules 2 and 3 could be helped along by tooling (compiler or
external).
Sounds good, but I'd like to see how this works in practice before going further
with it. The nice thing about this proposal is it involves no language changes.
On 2/9/2015 12:53 PM, Meta wrote:
On Monday, 9 February 2015 at 20:24:02 UTC, Walter Bright wrote:
On 2/9/2015 4:14 AM, Meta wrote:
Yes, but is it disabled by default in @trusted code?
It is never disabled by default.
Okay, I thought it was similar to @system in that respect.
@system
On Monday, 9 February 2015 at 12:02:12 UTC, John Colvin wrote:
On Monday, 9 February 2015 at 11:47:03 UTC, Meta wrote:
On Monday, 9 February 2015 at 11:43:00 UTC, Walter Bright
wrote:
On 2/9/2015 2:54 AM, John Colvin wrote:
It seems to me that rules 2 and 3 could be helped along by
tooling
On Monday, 9 February 2015 at 11:43:00 UTC, Walter Bright wrote:
On 2/9/2015 2:54 AM, John Colvin wrote:
It seems to me that rules 2 and 3 could be helped along by
tooling (compiler or
external).
Sounds good, but I'd like to see how this works in practice
before going further with it. The
On Monday, 9 February 2015 at 18:36:49 UTC, Steven Schveighoffer
wrote:
On 2/9/15 1:18 PM, Andrei Alexandrescu wrote:
On 2/9/15 10:12 AM, Steven Schveighoffer wrote:
On 2/9/15 12:57 PM, Andrei Alexandrescu wrote:
On 2/9/15 7:48 AM, Steven Schveighoffer wrote:
auto result = (() @trusted =
On Tuesday, 10 February 2015 at 04:18:16 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei
Alexandrescu wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to
save people
the awkward burden of importing it from
On 2/9/15 11:18 PM, Zach the Mystic wrote:
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to save people
the awkward burden of importing it from std.conv all the time.
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to
save people
the awkward burden of importing it from std.conv all the time.
But that
would be a language change, of
On 2/10/15 12:06 AM, Dicebot wrote:
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to save people
the awkward burden of importing it from std.conv all the time. But that
On 2/9/15 9:06 PM, Dicebot wrote:
On Tuesday, 10 February 2015 at 04:05:35 UTC, Andrei Alexandrescu wrote:
On 2/9/15 8:03 PM, Zach the Mystic wrote:
You could put the 'trusted' template right in object.d, to save people
the awkward burden of importing it from std.conv all the time. But that
50 matches
Mail list logo
