On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote:
On 5/24/2020 5:56 PM, Timon Gehr wrote:
It's only greenwashing if it's misleading. Putting @safe is a
lie, putting @trusted is honest.
It is not honest unless the programmer actually carefully
examined the interface and the documen
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
On 5/25/2020 7:04 PM, Johannes Loher wrote:
Now let's compare the two different options:
1. With DIP1028 in its current form, the code will compile and
a memory corruption will actually happen. The problem might be
extremely diffic
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
On 5/25/2020 7:04 PM, Johannes Loher wrote:
[..]
Do you honestly think option 1 is better?
Yes, for reasons I carefully laid out.
which fails to convince anyone because the reasoning is flawed.
> no clues whatsoever
He can l
On 5/25/2020 7:04 PM, Johannes Loher wrote:
Now let's compare the two different options:
1. With DIP1028 in its current form, the code will compile and a memory
corruption will actually happen. The problem might be extremely difficult to
track down for the developer because he has no clues wha
On Tuesday, 26 May 2020 at 01:16:49 UTC, Walter Bright wrote:
On 5/24/2020 5:56 PM, Timon Gehr wrote:
It's only greenwashing if it's misleading. Putting @safe is a
lie, putting @trusted is honest.
It is not honest unless the programmer actually carefully
examined the interface and the documen
On 5/24/2020 5:56 PM, Timon Gehr wrote:
It's only greenwashing if it's misleading. Putting @safe is a lie, putting
@trusted is honest.
It is not honest unless the programmer actually carefully examined the interface
and the documentation to determine if it is a safe interface or not. For
exam
Wowza, wow. The voice of reason returns!
The DIP is trying to accomplish (copied from its Rationale):
A. Costs of unsafe code have become ever more apparent and expensive,
and @safe has grown more capable. Users expect safety to be opt-out, not
opt-in.
B. Most code should be naturally safe, and system code should be
relatively rare
On Monday, 25 May 2020 at 19:59:57 UTC, Greatsam4sure wrote:
On Monday, 25 May 2020 at 04:16:57 UTC, zoujiaqing wrote:
On Friday, 22 May 2020 at 08:44:10 UTC, Greatsam4sure wrote:
On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote:
[...]
A holistic tutorial will help this framework
On Monday, 25 May 2020 at 19:44:00 UTC, Paul Backus wrote:
On Monday, 25 May 2020 at 19:35:04 UTC, Clarice wrote:
I really appreciate your contributions. (The latter of which
will be quite handy.) But isn't the whole point of Walter's
implementation of @safe-as-default is that FFIs are going
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
I share your concerns on this, but disagree on the likelihood
of reviews having gone by under the assumption of @system by
default. I doubt most people even thought about
@safe/@trusted/@system, and that's assuming anyone reviewed the
On Monday, 25 May 2020 at 04:16:57 UTC, zoujiaqing wrote:
On Friday, 22 May 2020 at 08:44:10 UTC, Greatsam4sure wrote:
On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote:
[...]
A holistic tutorial will help this framework more. The docs
are not helpful to me. This is the reason peop
On Monday, 25 May 2020 at 19:35:04 UTC, Clarice wrote:
I really appreciate your contributions. (The latter of which
will be quite handy.) But isn't the whole point of Walter's
implementation of @safe-as-default is that FFIs are going to be
assumed @safe? So they should still compile; that is
On Monday, 25 May 2020 at 17:31:29 UTC, Paul Backus wrote:
Even if you did review your code *and* all of your
dependencies, if you did it before DIP 1028 was accepted (i.e.,
any time in the last 10 years or so), you may have deliberately
left external @system functions un-annotated, because @sy
On Monday, 25 May 2020 at 18:39:16 UTC, mw wrote:
Can we declare the new D compiler version 3.0 for
@safe-as-default? and keep version 2.x compiler for the old
@system-as-default?
@safe-by-default is currently hidden behind a -preview switch. I
think it's safe to assume there will be a long
On Monday, 25 May 2020 at 17:31:29 UTC, Paul Backus wrote:
Even if you did review your code *and* all of your
dependencies, if you did it before DIP 1028 was accepted (i.e.,
any time in the last 10 years or so), you may have deliberately
left external @system functions un-annotated, because @sy
On Monday, 25 May 2020 at 17:09:50 UTC, Clarice wrote:
On Monday, 25 May 2020 at 16:47:50 UTC, Paul Backus wrote:
the compiler must warn D programmers that their declarations
need to be reviewed for compatibility with @safe-by-default.
Whether they were reviewed before that or not makes no
dif
On Monday, 25 May 2020 at 16:47:50 UTC, Paul Backus wrote:
the compiler must warn D programmers that their declarations
need to be reviewed for compatibility with @safe-by-default.
Whether they were reviewed before that or not makes no
difference.
I'm not an engineer; I'm not learned in CS. S
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
A few years ago I submitted several PRs to Phobos to mark all
unittests that could with @safe explicitly. I'd say that was a
good example of nobody reviewing them for their @systemness.
Ideally you should be able to blindly mark every
On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote:
On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
If we were designing a new language from scratch, I would
agree 100% with your reasoning.
The problem is that there are un-annotated declarations in
existing code that have
On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote:
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
I'd like to emphasize:
1. It is not possible for the compiler to check any
declarations where the implementation is not available. Not in
D, not in any language. Declaring a
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote:
The more I think of Atila's and Walter's responses, the more
they are starting to make sense.
[...]
Thank you for the anecdote, especially since it captures the
spirit of what I've been trying to convey here.
On Friday, 22 May 2020 at 20:08:37 UTC, Dukc wrote:
On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
Sorry, I didn't express myself well. I meant that the user can
still mark functions as @system, they just have to do it
explicitly.
Hm, DPP might be of help here. Becuse I quess yo
On Monday, 25 May 2020 at 15:07:19 UTC, Petar Kirov [ZombineDev]
wrote:
I don't want to change the definition of @safe in D, but would
rather like if D supported @strongSafe, that interested people
like me could opt into.
I know that worded like this it may sound like too narrow
feature to add
On Monday, 25 May 2020 at 13:43:07 UTC, Paul Backus wrote:
On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov
[ZombineDev] wrote:
On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov
[ZombineDev] wrote:
It may be true (of course modulo meta-programming) that it
doesn't make a difference for t
On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov [ZombineDev]
wrote:
On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov
[ZombineDev] wrote:
It may be true (of course modulo meta-programming) that it
doesn't make a difference for the calling code, but I
personally want have the guarantees
On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov [ZombineDev]
wrote:
It may be true (of course modulo meta-programming) that it
doesn't make a difference for the calling code, but I
personally want have the guarantees that a function that I'm
doesn't make a difference for the calling code
On Monday, 25 May 2020 at 12:41:01 UTC, Paul Backus wrote:
On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
It is meant to mean that at some point it has been
mechanically checked by the compiler.
Either during current comp
On 25.05.20 14:22, Johannes T wrote:
Sorry, I phrased it poorly. I meant @trusted would be used more
frequently. The focus would spread and lead to less rigorous checks.
The focus is as wide as it's ever been. If you want to verify a program,
you have to check those prototypes, whether they're
On 25.05.20 14:22, Johannes T wrote:
On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote:
On 25.05.20 11:25, Johannes T wrote:
@trusted can't be trusted
That's the point of @trusted. ._.
The code is trusted by the programmer, not the annotation by the
compiler.
Sorry, I phrased it po
On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
[..]
But with the DIP in its current form, we make @safe lose its
meaning and power, which is much worse in my opinion.
[..]
The alternative, not making extern @safe, would
On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
It is meant to mean that at some point it has been
mechanically checked by the compiler.
Either during current compilation or a prior one.
Which means it has to be valid on f
On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote:
[..]
there is no such thing as a trustworthy @trusted.
[..]
Sorry, my bad. I meant the quality of @trusted annotations would
decline.
On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
On 25/05/2020 10:29 PM, Zoadian wrote:
you complain about @trusted losing it's meaning, but @safe was
ment to mean "mechanically verified memory safety". it should
be forbidden to add @safe to any function that can not be
verified
On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
[..]
But with the DIP in its current form, we make @safe lose its
meaning and power, which is much worse in my opinion.
[..]
The alternative, not making extern @safe, would
On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote:
there is no such thing as a trustworthy @trusted. not with how
the whole safety system work now.
you can break previously verified @trusted code by just writing
@safe code today.
Do you have an example of code that was correctly labeled
On Monday, 25 May 2020 at 11:40:46 UTC, Johannes T wrote:
On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
[..]
But with the DIP in its current form, we make @safe lose its
meaning and power, which is much worse in my opinion.
[..]
The alternative, not making extern @safe, would
On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote:
On 25.05.20 11:25, Johannes T wrote:
@trusted can't be trusted
That's the point of @trusted. ._.
The code is trusted by the programmer, not the annotation by
the compiler.
Sorry, I phrased it poorly. I meant @trusted would be used m
On 25.05.20 11:25, Johannes T wrote:
@trusted can't be trusted
That's the point of @trusted. ._.
The code is trusted by the programmer, not the annotation by the compiler.
On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote:
[..]
But with the DIP in its current form, we make @safe lose its
meaning and power, which is much worse in my opinion.
[..]
The alternative, not making extern @safe, would result in more
untrustworthy @trusted code we have to wor
On Saturday, 23 May 2020 at 15:04:35 UTC, Paulo Pinto wrote:
Hi everyone,
as the subject states, you can find it here,
https://codefence.io/
The current version is 2.092.0 with dmd.
SOB
！
On 25/05/2020 10:29 PM, Zoadian wrote:
you complain about @trusted losing it's meaning, but @safe was ment to
mean "mechanically verified memory safety". it should be forbidden to
add @safe to any function that can not be verified by the compiler.
It is meant to mean that at some point it has
On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote:
On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
[..]
After thinking about it, Walter ultimately made the right
decision, leading to overall higher safety and code quality.
We all agree that making extern C @safe is incorrect.
On Monday, 25 May 2020 at 09:25:52 UTC, Johannes T wrote:
On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
[..]
After thinking about it, Walter ultimately made the right
decision, leading to overall higher safety and code quality.
We all agree that making extern C @safe is incorrect.
On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote:
[..]
After thinking about it, Walter ultimately made the right
decision, leading to overall higher safety and code quality.
We all agree that making extern C @safe is incorrect. It's also
meaningless. Even if you were to verify the saf
On 5/23/2020 5:13 AM, Steven Schveighoffer wrote:
And let's be honest here, if you are OK with it, putting @trusted: at the top of
your extern(C) functions is fine with me. At least that's not a lie.
@trusted says the interface to the function is safe. If the programmer did not
actually check
46 matches
Mail list logo
