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 3:30:32 AM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:
> On 5/27/20 1:49 AM, Walter Bright wrote:
> > On 5/26/2020 9:31 AM, Bruce Carneal wrote:
> >> Currently a machine checked @safe function calling an unannotated
> >> extern C routine will error out
On Tuesday, May 26, 2020 8:58:16 PM MDT Andrei Alexandrescu via Digitalmars-d-
announce wrote:
> On 5/26/20 12:31 PM, Bruce Carneal wrote:
> > Currently a machine checked @safe function calling an unannotated extern
> > C routine will error out during compilation. This is great as the C
> >
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 10:51:54 UTC, Walter Bright wrote:
[..]
I was reading Bastiaan's inspiring ideas about provable
verification of @trusted and something occurred to me. If we are
serious about safety, we should consider @trusted annotation on
extern C harmful. It provides little
I'm curious what the distribution looks like between whether
people agree that extern(C) should be @safe, or @system. People
that think it should be @trusted, vote @safe, it's pretty much
the same thing.
https://www.strawpoll.me/20184671
On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
[snip]
Nothing at all.
But I doubt there is much legacy non-compiling code around.
I cannot speak for all the code out there, but I know of at least
one binding out there [1] that will need to get updated in light
of this DIP.
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:50:25 UTC, Bruce Carneal wrote:
On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote:
[...]
You continue to miss the point.
Additionally, there never was any "working legacy code". As
established, the pre 1080 compiler would have rejected the
On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote:
On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of
this nature.
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 10:51:54 UTC, Walter Bright wrote:
On 5/27/2020 3:01 AM, Timon Gehr wrote:
I've addressed exactly this a dozen times or more, to you and
others. Repeating myself has become pointless.
It's fine to disagree with me. Argue that point. But don't say
I didn't address
On Wednesday, 27 May 2020 at 05:54:32 UTC, Walter Bright wrote:
On 5/26/2020 1:32 PM, Paul Backus wrote:
The reason extern function declarations are particularly
problematic is that changing them from @system-by-default to
@safe-by-default can cause *silent* breakage in existing,
correct
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 28/05/2020 12:33 AM, aberba wrote:
On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote:
On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via
Digitalmars-d-announce wrote: [...]
Even if we suppose for the sake of argument that the decision is
sound on a technical level, this
On 27.05.20 12:51, Walter Bright wrote:
On 5/27/2020 3:01 AM, Timon Gehr wrote:
This is clearly not possible, exactly because the old @safe rules are
stronger.
Thank you. We can agree on something.
...
I am not sure if you noticed that I agree with most of your points, just
not about
On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote:
On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via
Digitalmars-d-announce wrote: [...]
Even if we suppose for the sake of argument that the decision
is sound on a technical level, this is poor leadership, and
bodes ill for
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.
On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote:
On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of
this nature.
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:01 AM, Timon Gehr wrote:
This is clearly not possible, exactly because the old @safe rules are stronger.
Thank you. We can agree on something.
But why exactly should API breakage not count?
I've addressed exactly this a dozen times or more, to you and others. Repeating
On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of this nature.
Apparently you agree it is not an actual problem.
Really? I don't
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.20 07:54, Walter Bright wrote:
On 5/26/2020 1:32 PM, Paul Backus wrote:
The reason extern function declarations are particularly problematic
is that changing them from @system-by-default to @safe-by-default can
cause *silent* breakage in existing, correct code.
Can you post an
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 27.05.20 11:34, Bastiaan Veelo wrote:
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of this nature.
Apparently you agree it is not an actual problem.
Really? I don't
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 Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
On 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of
this nature.
Apparently you agree it is not an actual problem.
Really? I don't know if you really missed the point being
On 5/27/20 1:49 AM, Walter Bright wrote:
On 5/26/2020 9:31 AM, Bruce Carneal wrote:
Currently a machine checked @safe function calling an unannotated
extern C routine will error out during compilation. This is great as
the C routine was not machine checked, and generally can not be
checked.
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 5/26/2020 11:20 PM, Bruce Carneal wrote:
I'm not at all concerned with legacy non-compiling code of this nature.
Apparently you agree it is not an actual problem.
On Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
On 5/26/2020 9:31 AM, Bruce Carneal wrote:
Currently a machine checked @safe function calling an
unannotated extern C routine will error out during
compilation. This is great as the C routine was not machine
checked, and
On Wednesday, 27 May 2020 at 02:58:16 UTC, Andrei Alexandrescu
wrote:
On 5/26/20 12:31 PM, Bruce Carneal wrote:
Currently a machine checked @safe function calling an
unannotated extern C routine will error out during
compilation. This is great as the C routine was not machine
checked, and
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 Wednesday, 27 May 2020 at 05:49:49 UTC, Walter Bright wrote:
On 5/26/2020 9:31 AM, Bruce Carneal wrote:
Currently a machine checked @safe function calling an
unannotated extern C routine will error out during
compilation. This is great as the C routine was not machine
checked, and
59 matches
Mail list logo
