On Thursday, 28 May 2020 at 02:39:40 UTC, Jonathan M Davis wrote:
On Wednesday, May 27, 2020 8:13:52 PM MDT Bruce Carneal via
Digitalmars-d- announce wrote:
On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis
wrote:
> [...]
I remember reading a suggestion that additional linker symbols
On Wednesday, May 27, 2020 8:13:52 PM MDT Bruce Carneal via Digitalmars-d-
announce wrote:
> On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis wrote:
> > On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via
> >
> > Digitalmars-d- announce wrote:
> >> [...]
> >
> > Except that the
On Wednesday, May 27, 2020 6:24:25 PM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:
> On 5/27/20 9:42 AM, Andrej Mitrovic wrote:
> > On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
> >> Un-annotated C declarations should be a red flag to any competent QA
> >> team.
On Thursday, 28 May 2020 at 01:14:43 UTC, Jonathan M Davis wrote:
On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via
Digitalmars-d- announce wrote:
[...]
Except that the linker matters a great deal in this discussion
with regards to extern(D) functions, because @safe and @trusted
On Friday, May 22, 2020 9:29:03 AM MDT Timon Gehr via Digitalmars-d-announce
wrote:
> On 22.05.20 16:49, bachmeier wrote:
> > I don't see that marking an extern(C) function @trusted buys you
> > anything, at least not until you can provide a compiler guarantee for
> > arbitrary C code.
>
> It
On Friday, May 22, 2020 12:09:16 PM MDT rikki cattermole via Digitalmars-d-
announce wrote:
> It kept being swapped about in the discussion thread, so I have been a
> little on edge over people using non-extern(D). Because linkage doesn't
> mean anything to anything but to cpu and linker in this
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic wrote:
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to multiple
symbols. Only allow `@trusted` to apply to a single symbol. For
example:
That came to my mind immediately. I'm not entirely
On Friday, 22 May 2020 at 18:14:12 UTC, H. S. Teoh wrote:
Then myFunc would become callable from @safe code, provided the
passed-in argument is also @safe.
The crucial point here is that while compiling myFunc, the
compiler doesn't (need to) know the @safe-ty of `cb`, it can
just treat it as
On 5/27/20 9:42 AM, Andrej Mitrovic wrote:
On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
Un-annotated C declarations should be a red flag to any competent QA
team. Recognizing a false @trusted is a whole lot harder.
Is the actual problem those `@trusted:` declarations at the
On Wednesday, 27 May 2020 at 13:47:46 UTC, Claude wrote:
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic
wrote:
Is the actual problem those `@trusted:` declarations at the
top of C headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to
On Wednesday, 27 May 2020 at 13:47:46 UTC, Claude wrote:
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic
wrote:
Is the actual problem those `@trusted:` declarations at the
top of C headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
I have made these points before, but I'll summarize them here
for convenient referral.
[big snip of very long and arguably tangential Java screw-up and
other]
How does this relate to safe by default?
Consider the common (because
On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic wrote:
Is the actual problem those `@trusted:` declarations at the top
of C headers?
There could be a simple solution to that:
Ban `@trusted:` and `@trusted { }` which apply to multiple
symbols. Only allow `@trusted` to apply to a
On Wednesday, 27 May 2020 at 10:07:48 UTC, Johannes Loher wrote:
Am 27.05.20 um 11:50 schrieb Walter Bright:
[...]
Un-annotated C declarations should be a red flag to any
competent QA team. Recognizing a false @trusted is a whole lot
harder.
[...]
Also in my opinion, a competent QA
On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
Un-annotated C declarations should be a red flag to any
competent QA team. Recognizing a false @trusted is a whole lot
harder.
Is the actual problem those `@trusted:` declarations at the top
of C headers?
There could be a
On Wednesday, 27 May 2020 at 11:46:40 UTC, Andrei Alexandrescu
wrote:
On 5/27/20 6:22 AM, Walter Bright wrote:
On 5/27/2020 3:06 AM, rikki cattermole wrote:
Open to everybody and it can be recorded by Twitch.
I've done the video conferencing many times over the decades.
I just don't find it
On Wednesday, 27 May 2020 at 10:03:21 UTC, Walter Bright wrote:
It's not an acceptable solution for people who require
correctness. ZombineDev can't tell an auditor that he relies
on D-Scanner to find the problematic spots. I believe it's
unavoidable to provide an option to change the default.
On 27/5/20 11:50, Walter Bright wrote:
It is a fair point. But I am looking a bit farther than that - the team
that is responsible for QAing software (sometimes it is a separate
team). The QA team cannot tell the difference between correctly
annotated @trusted code and greenwashed code.
On 5/27/20 6:22 AM, Walter Bright wrote:
On 5/27/2020 3:06 AM, rikki cattermole wrote:
Open to everybody and it can be recorded by Twitch.
I've done the video conferencing many times over the decades. I just
don't find it to be productive. Maybe it's some defect in me.
They usually go
On Wednesday, 27 May 2020 at 10:40:18 UTC, Walter Bright wrote:
On 5/27/2020 3:07 AM, Johannes Loher wrote:
This is a very specific situation. There are a lot of teams /
developers
that do not work in this manner. I don't know the numbers so I
will make
no statement about what is more common
On 5/27/20 6:03 AM, Walter Bright wrote:
On 5/26/2020 5:20 AM, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative feedback.
I get your decision to not annotate extern C with @system by default.
Am 27.05.20 um 12:40 schrieb Walter Bright:
>
> Indeed it is, and that's the whole point to @safe. My motivation here is
> make suspicious code stand out. @trusted code does not stand out so
> much, because it is required to exist.
By that logic, wouldn't it also make more sense to implicitly
On 5/27/2020 3:07 AM, Johannes Loher wrote:
This is a very specific situation. There are a lot of teams / developers
that do not work in this manner. I don't know the numbers so I will make
no statement about what is more common but my personal experience is a
different one.
I've seen larger
Am 27.05.20 um 11:50 schrieb Walter Bright:
>
> It is a fair point.
>
By the way, thank you for acknowledging that. I appreciate it.
On 27/05/2020 10:12 PM, Johannes Loher wrote:
Am 27.05.20 um 11:25 schrieb Walter Bright:
On 5/24/2020 3:40 AM, Stefan Koch wrote:
The distinction is that you can find a slapped on trusted with a grep.
It's just as easy to use grep to *not* find @trusted.
But that's not enough. You need a
On 5/27/2020 3:06 AM, rikki cattermole wrote:
Open to everybody and it can be recorded by Twitch.
I've done the video conferencing many times over the decades. I just don't find
it to be productive. Maybe it's some defect in me.
They usually go something like this:
"Who else is here?"
On Wednesday, 27 May 2020 at 10:06:41 UTC, rikki cattermole wrote:
On 27/05/2020 10:03 PM, Walter Bright wrote:
Frankly, I feel that if I could sit down with you folks, I can
get the idea across what I'm trying to accomplish.
Okay, how is your camera and mic situation?
Lets do a Twitch
Am 27.05.20 um 11:25 schrieb Walter Bright:
> On 5/24/2020 3:40 AM, Stefan Koch wrote:
>> The distinction is that you can find a slapped on trusted with a grep.
>
> It's just as easy to use grep to *not* find @trusted.
But that's not enough. You need a regexp that searches for extern
(C(++))
On 5/26/2020 6:07 AM, Panke wrote:
On Tuesday, 26 May 2020 at 12:20:31 UTC, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative feedback.
Yes, good think to stop once in a while and appreciate it.
Am 27.05.20 um 11:50 schrieb Walter Bright:
> It is a fair point. But I am looking a bit farther than that - the team
> that is responsible for QAing software (sometimes it is a separate
> team). The QA team cannot tell the difference between correctly
> annotated @trusted code and greenwashed
On 27/05/2020 10:03 PM, Walter Bright wrote:
Frankly, I feel that if I could sit down with you folks, I can get the
idea across what I'm trying to accomplish.
Okay, how is your camera and mic situation?
Lets do a Twitch stream, make sure there are some moderators in place as
well.
Open to
On 5/26/2020 5:20 AM, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative feedback. I get your
decision to not annotate extern C with @system by default. The biggest issue
with extern @system is
On 27/05/2020 9:50 PM, Walter Bright wrote:
BTW, one good thing that has come out of this issue is people are
strongly in favor of what @safe does. That bodes well for DIP1000 and
the @live code, for a long time I seemed to be the only one who cared
about it.
Most of the arguments against
On 5/26/2020 12:18 AM, Johannes Loher wrote:
Just think about what the developer's reaction would be in the situation I
described in my last post, when he actually finds the issue.
In your variant, the developer will be questioning why the compiler did not help
him at all with realizing that
On 5/24/2020 3:40 AM, Stefan Koch wrote:
The distinction is that you can find a slapped on trusted with a grep.
It's just as easy to use grep to *not* find @trusted.
On Wednesday, 27 May 2020 at 02:42:24 UTC, Walter Bright wrote:
On 5/24/2020 6:04 PM, Timon Gehr wrote:
Implicit greenwashing by the compiler is a nuisance that makes
it harder to do the job correctly and easier to do the wrong
thing.
You and I are just going to disagree about that.
On 5/24/2020 6:04 PM, Timon Gehr wrote:
Implicit greenwashing by the compiler is a nuisance that makes it harder to do
the job correctly and easier to do the wrong thing.
You and I are just going to disagree about that.
On 5/25/20 5:17 AM, Walter Bright wrote:
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
On Tuesday, 26 May 2020 at 12:51:59 UTC, Atila Neves wrote:
On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
If the greenwashing part was separated and delayed it would
give time to find out if Walters
On Tuesday, 26 May 2020 at 12:51:59 UTC, Atila Neves wrote:
On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
If the greenwashing part was separated and delayed it would
give time to find out if Walters
On Tuesday, 26 May 2020 at 13:21:08 UTC, Johannes Loher wrote:
Am 26.05.20 um 15:10 schrieb Panke:
The bazel community has lots of such switches. Basically every
new behaviour get's introduced with a --preview switch, that
will turn into a --revert after some time.
For each switch there is
Am 26.05.20 um 15:10 schrieb Panke:
>
> The bazel community has lots of such switches. Basically every new
> behaviour get's introduced with a --preview switch, that will turn into
> a --revert after some time.
>
> For each switch there is a github issue, explaining the change it
> detail. Why
On Tuesday, 26 May 2020 at 12:38:54 UTC, Johannes Loher wrote:
A switch might help but the whole purpose of this DIP is to get
the defaults right. In my opinion, such a switch should be
enabled by default. There is also the danger of creating 2
versions of the language that are incompatible
On Tuesday, 26 May 2020 at 12:20:31 UTC, Johannes T wrote:
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative
feedback.
Yes, good think to stop once in a while and appreciate it. "To
not complain is sufficient
On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote:
On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov
[ZombineDev] wrote:
[...]
If the greenwashing part was separated and delayed it would
give time to find out if Walters hypothesis about people just
doing it themselves is true.
Am 26.05.20 um 14:20 schrieb Johannes T:
> Thank you very much for your patience with all the negative feedback. I
> get your decision to not annotate extern C with @system by default.
As much as i disagree with the decision, I am still very glad that we
are at least having a discussion. I also
On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev]
wrote:
On Monday, 25 May 2020 at 23:39:33 UTC, Andrei Alexandrescu
wrote:
[..]
Thank you, Andrei, you've put this quite eloquently. With more
than 200+ replies, unfortunately, this whole discussion looks
like an excessively
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
[..]
Thank you very much for your patience with all the negative
feedback. I get your decision to not annotate extern C with
@system by default. The biggest issue with extern @system is that
@trusted would become less useful when
On 26.05.20 13:09, Atila Neves wrote:
On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
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
On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote:
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
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
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
2. Make @safe the default for _all_ declarations but still make
@safe on declarations without code a compile error (because the
compiler cannot verify it). This means that annotating function
declarations without code with @system
On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
He can look at unattributed declarations.
The issue is, you have to know about that beforehand. In the
other situation, you explicitly get warned by the compiler (by
the compile error) that that something dangerous is going on.
On Tuesday, 26 May 2020 at 02:04:02 UTC, Johannes Loher wrote:
According to your argument of „convenience“, the developer will
probably just mark the function incorrectly as @trusted which
makes the code compile. The memory corruption will happen.
However, even if the developer did not think
On Monday, 25 May 2020 at 23:39:33 UTC, Andrei Alexandrescu wrote:
[..]
Thank you, Andrei, you've put this quite eloquently. With more
than 200+ replies, unfortunately, this whole discussion looks
like an excessively inefficient use of the community's time.
One way to resolve this
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 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
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
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
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/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
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
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 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
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 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: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 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 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
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
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
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
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 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 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 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 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 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
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 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 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
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
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 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 Monday, 25 May 2020 at 01:04:24 UTC, Timon Gehr wrote:
On 24.05.20 11:10, Walter Bright wrote:
On 5/23/2020 11:26 PM, Bruce Carneal wrote:
I don't believe that you or any other competent programmer
greenwashes safety critical code. Regardless, the safety
conscious must review their
On 24.05.20 11:10, Walter Bright wrote:
On 5/23/2020 11:26 PM, Bruce Carneal wrote:
I don't believe that you or any other competent programmer greenwashes
safety critical code. Regardless, the safety conscious must review
their dependencies whatever default applies.
That's the theory. But
1 - 100 of 221 matches
Mail list logo
