On 2015-02-05 22:35, Walter Bright wrote:
It's no different from:
Q: the compiler gave me a mismatched type error!
A: put in a cast and it'll compile!
The difference is if you do that the compiler won't disable type
checking for the whole function.
--
/Jacob Carlborg
On 2/6/2015 8:10 AM, Andrei Alexandrescu wrote:
On 2/6/15 3:26 AM, Tobias Pankrath wrote:
I'd like D to provide the following guarantee: If I corrupt my memory
using @safe code, the error must be in code marked @trusted / @system,
either because the do not provide a @safe interface or because
On Friday, 6 February 2015 at 06:25:06 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 8:24 PM, Dicebot wrote:
I referred to this fact with a comment it is better to make no
promises than to make one and break it. Simply dealing with
unsafe language is something I got used to - all crashes and
weird
On 2/6/15 3:26 AM, Tobias Pankrath wrote:
I'd like D to provide the following guarantee: If I corrupt my memory
using @safe code, the error must be in code marked @trusted / @system,
either because the do not provide a @safe interface or because they are
buggy.
That's what we're going for. --
On 2/5/2015 8:24 PM, Dicebot wrote:
What is worse, as it has been already mentioned, it is not just a
one time effort - careful review necessity taints all code that
gets called from @trusted code.
That is only true if the @trusted code has an unsafe interface. Determining if a
function has a
On 2/5/15 8:24 PM, Dicebot wrote:
I referred to this fact with a comment it is better to make no
promises than to make one and break it. Simply dealing with
unsafe language is something I got used to - all crashes and
weird think become expected. It is totally different from seeing
a memory
On Friday, 6 February 2015 at 00:56:09 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 4:37 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:31:06 UTC, Andrei
Alexandrescu wrote:
On 2/5/15 4:22 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:21:45 UTC, Andrei
Alexandrescu wrote:
On 2/5/15
On Thursday, 5 February 2015 at 20:13:32 UTC, Walter Bright wrote:
On 2/5/2015 11:49 AM, Andrei Alexandrescu wrote:
As much as I was shocked about the use of
@trusted/@safe/@system in std.file,
std.array and sadly possibly in other places, I found no
evidence that the
feature is misdesigned. I
On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
On 2/5/15 3:13 PM, Walter Bright wrote:
So the question is, what does @trusted actually buy you, since the
compiler can't check it?
It serves as notice that This function merits special attention during
code review to check that it has a safe
On Thursday, 5 February 2015 at 21:15:52 UTC, Steven
Schveighoffer wrote:
An aspect of a well-designed encapsulation is the number of
@trusted
interfaces is minimized. If you find an abstraction that has
@trusted
sprinkled liberally through it, it's an indicator of a failed
abstraction.
I
On 2/5/15 3:54 PM, Walter Bright wrote:
On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
On 2/5/15 3:13 PM, Walter Bright wrote:
So the question is, what does @trusted actually buy you, since the
compiler can't check it?
It serves as notice that This function merits special attention during
On 2/5/15 12:24 PM, Zach the Mystic wrote:
At minimum, there needs to be official documented guidance on how to use
@trusted. If phobos developers got this far without knowing how to use
it (assuming their complaints on its design are indeed meritless), how
can anyone else be expected to?
Yah,
On 2/5/2015 1:15 PM, Steven Schveighoffer wrote:
So you're saying that @safe is mechanically verified as long as @trusted
functions are manually reviewed.
Yes.
It's that manually reviewed part that I think
we have an issue with. And there is definitely a feel of I can use trusted
because I
On Thu, Feb 05, 2015 at 03:39:16PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
I think the *fundamental* problem with @trusted (currently) is that it
assumes all the code it covers was written simultaneously and is not
allowed to morph. This isn't the way code is written, it's
On 2/5/15 1:54 PM, H. S. Teoh via Digitalmars-d wrote:
However, I don't agree that the entire function can be marked @safe.
Otherwise, @safe code will now contain arbitrary @trusted blocks inside,
and so anybody can freely escape @safe restrictions just by putting
objectionable operations
On Thu, Feb 05, 2015 at 06:56:02PM +, Zach the Mystic via Digitalmars-d
wrote:
On Thursday, 5 February 2015 at 18:21:40 UTC, Steven Schveighoffer wrote:
On 2/5/15 1:12 PM, Zach the Mystic wrote:
Hey I like the creativity you're showing. Just to give people a
concrete idea, you might
To put it differently - there is no way I would have ever taken
the risk merging a 50-line @trusted function, be it Phobos or
work project. And it is better to not make promises than to break
those.
On Thursday, 5 February 2015 at 19:49:41 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
In short, my proposal is:
Tainted variables are an interesting topic, but quite distinct
from the notion of separating safe code from unsafe code.
As much as I
On 2/5/2015 3:20 PM, Dicebot wrote:
For me this thread was clear alarm : @safe in its current state is a 100%
misfeature and is better to be advertised against until either its design
changes or effective idioms are presented.
I try to address your points in the new thread @trust is an
On 2/5/15 3:22 PM, Dicebot wrote:
To put it differently - there is no way I would have ever taken the risk
merging a 50-line @trusted function, be it Phobos or work project.
Surely you're exaggerating. We're looking at a function that performs
system calls and reads into a memory buffer
On Thursday, 5 February 2015 at 23:47:00 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 3:22 PM, Dicebot wrote:
To put it differently - there is no way I would have ever
taken the risk
merging a 50-line @trusted function, be it Phobos or work
project.
Surely you're exaggerating.
Not even
On 2/5/15 4:22 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:21:45 UTC, Andrei Alexandrescu wrote:
On 2/5/15 4:02 PM, Dicebot wrote:
Verifying 50 lines of @trusted with no help from compiler at all is
beyond those limits.
Do you use @safe at work? -- Andrei
If it is sarcasm, it could
On Friday, 6 February 2015 at 00:31:06 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 4:22 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:21:45 UTC, Andrei
Alexandrescu wrote:
On 2/5/15 4:02 PM, Dicebot wrote:
Verifying 50 lines of @trusted with no help from compiler at
all is
beyond those
On Friday, 6 February 2015 at 00:21:45 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 4:02 PM, Dicebot wrote:
Verifying 50 lines of @trusted with no help from compiler at
all is
beyond those limits.
Do you use @safe at work? -- Andrei
If it is sarcasm, it could have been better.
On 2/5/15 4:02 PM, Dicebot wrote:
Verifying 50 lines of @trusted with no help from compiler at all is
beyond those limits.
Do you use @safe at work? -- Andrei
Reading the thread in bug report
https://issues.dlang.org/show_bug.cgi?id=14125 gets me thinking, perhaps
@trusted is mis-designed.
At the moment, a @trusted function is the same as a @system function,
but is allowed to be called from a @safe function. And that's it.
But a @trusted function
On 2/5/15 4:37 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:31:06 UTC, Andrei Alexandrescu wrote:
On 2/5/15 4:22 PM, Dicebot wrote:
On Friday, 6 February 2015 at 00:21:45 UTC, Andrei Alexandrescu wrote:
On 2/5/15 4:02 PM, Dicebot wrote:
Verifying 50 lines of @trusted with no help from
On 2/5/2015 4:02 PM, Dicebot wrote:
I have revoked my Phobos access for a specific reason that I
can't do the reviewer job properly with such requirements and would have been
forced to ignore all pull requests that tackle @trusted anyway.
It's appropriate to recuse yourself from reviewing
On 2/5/15 1:12 PM, Zach the Mystic wrote:
Hey I like the creativity you're showing. Just to give people a concrete
idea, you might show some sample code and illustrate how things work. It
sure helps when I'm trying to think about things.
So for example:
@safe int *foo()
{
int *x;
int
On Thu, Feb 05, 2015 at 11:50:18AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
Reading the thread in bug report
https://issues.dlang.org/show_bug.cgi?id=14125 gets me thinking,
perhaps @trusted is mis-designed.
That's the feeling I'm getting too!
Well, to be fair, I can see why it
On Thursday, 5 February 2015 at 18:21:40 UTC, Steven
Schveighoffer wrote:
On 2/5/15 1:12 PM, Zach the Mystic wrote:
Hey I like the creativity you're showing. Just to give people
a concrete
idea, you might show some sample code and illustrate how
things work. It
sure helps when I'm trying
On Thursday, 5 February 2015 at 16:50:18 UTC, Steven
Schveighoffer wrote:
I've left some of the details fuzzy on purpose, because I'm not
a compiler writer :)
So you want to spend another 8 years implementing linear typing
for D:
http://en.wikipedia.org/wiki/Substructural_type_system
Or
On Thursday, 5 February 2015 at 16:50:18 UTC, Steven
Schveighoffer wrote:
Reading the thread in bug report
https://issues.dlang.org/show_bug.cgi?id=14125 gets me
thinking, perhaps @trusted is mis-designed.
At the moment, a @trusted function is the same as a @system
function, but is allowed
On Thu, Feb 05, 2015 at 02:11:32PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/5/15 1:54 PM, H. S. Teoh via Digitalmars-d wrote:
However, I don't agree that the entire function can be marked @safe.
Otherwise, @safe code will now contain arbitrary @trusted blocks inside,
and so
On Thursday, 5 February 2015 at 19:19:51 UTC, H. S. Teoh wrote:
- @safe should continue being @safe -- no (potentially) unsafe
operations are allowed, period.
Rationale: allowing @system variables in @safe code makes the
function
non-verifiable mechanically. This completely breaks the
On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
In short, my proposal is:
Tainted variables are an interesting topic, but quite distinct from the
notion of separating safe code from unsafe code.
As much as I was shocked about the use of @trusted/@safe/@system in
std.file, std.array
On 2/5/15 2:17 PM, H. S. Teoh via Digitalmars-d wrote:
I mostly like this idea, except that foo() should not be marked @safe.
It should be marked @trusted because it still needs review, but the
meaning of @trusted should be changed so that it still enforces
@safe-ty, except that now @trusted
On Thu, Feb 05, 2015 at 11:49:40AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
In short, my proposal is:
Tainted variables are an interesting topic, but quite distinct from
the notion of separating safe code from unsafe code.
On 2/5/2015 11:49 AM, Andrei Alexandrescu wrote:
As much as I was shocked about the use of @trusted/@safe/@system in std.file,
std.array and sadly possibly in other places, I found no evidence that the
feature is misdesigned. I continue to consider it a simple, sound, and very
effective method
On 2/5/15 2:43 PM, H. S. Teoh via Digitalmars-d wrote:
The idea is that while we would like the compiler to mechanically verify
*everything*, in practice there are some things that the compiler simply
cannot verify. Since those remaining things require human effort to
verify and humans are
On 2/5/15 2:49 PM, Andrei Alexandrescu wrote:
On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
In short, my proposal is:
Tainted variables are an interesting topic, but quite distinct from the
notion of separating safe code from unsafe code.
As much as I was shocked about the use of
On Thursday, 5 February 2015 at 19:49:41 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
In short, my proposal is:
Tainted variables are an interesting topic, but quite distinct
from the notion of separating safe code from unsafe code.
As much as I
On Thu, Feb 05, 2015 at 03:14:18PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/5/15 2:43 PM, H. S. Teoh via Digitalmars-d wrote:
The idea is that while we would like the compiler to mechanically
verify *everything*, in practice there are some things that the
compiler simply
On 2/5/15 3:13 PM, Walter Bright wrote:
On 2/5/2015 11:49 AM, Andrei Alexandrescu wrote:
As much as I was shocked about the use of @trusted/@safe/@system in
std.file,
std.array and sadly possibly in other places, I found no evidence that
the
feature is misdesigned. I continue to consider it a
On 2/5/15 3:23 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Feb 05, 2015 at 03:14:18PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
On 2/5/15 2:43 PM, H. S. Teoh via Digitalmars-d wrote:
The idea is that while we would like the compiler to mechanically
verify *everything*, in
45 matches
Mail list logo
