On 2020-05-24 00:15, Walter Bright wrote:
On 5/23/2020 4:26 AM, Faux Amis wrote:
Just a suggestion, but sometimes matters are best discussed over
audio/video. Would having a public teams/zoom/.. meeting be helpful?
I would definitely listen/watch; even if I were muted and could only
chat
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
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
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 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 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
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
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 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
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 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
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
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 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,
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,
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
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
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
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
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 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,
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
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
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 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
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
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 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.
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
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
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 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
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
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
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 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 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
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
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
Wowza, wow. The voice of reason returns!
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
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
44 matches
Mail list logo
