On Friday, 29 May 2020 at 11:33:01 UTC, Sebastiaan Koppe wrote:
On Thursday, 28 May 2020 at 16:01:35 UTC, Johannes Pfau wrote:
[snip]
This would be another round of massively breaking user code.
The breakage will be split in two rounds, but the amount of
code needed to be modified would be
On Thursday, 28 May 2020 at 16:01:35 UTC, Johannes Pfau wrote:
Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe:
If it does come back to haunt him, he can always add a DIP to
make extern(!D) @system by default. It won't invalidate any
work.
This would be another round of massively
On Friday, 29 May 2020 at 06:55:07 UTC, Robert M. Münch wrote:
On 2020-05-27 06:59:28 +, Bruce Carneal said:
Walter has confirmed that this is indeed the case. As you can
read a few posts up his response to my "What am I missing?"
query was "Nothing at all."
Yes, it's really that bad.
On 2020-05-27 06:59:28 +, Bruce Carneal said:
Walter has confirmed that this is indeed the case. As you can read a
few posts up his response to my "What am I missing?" query was "Nothing
at all."
Yes, it's really that bad.
Will it be possible to see a report of these "greenwashed"
On Thursday, 28 May 2020 at 12:28:16 UTC, Sebastiaan Koppe wrote:
On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis
wrote:
He did unfortunately manage to convince Atila, so the DIP has
been accepted, but based on the discussions, I think that you
may be the only person I've seen say
Am Thu, 28 May 2020 12:28:16 + schrieb Sebastiaan Koppe:
> On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote:
>> He did unfortunately manage to convince Atila, so the DIP has been
>> accepted, but based on the discussions, I think that you may be the
>> only person I've seen
Am Thu, 28 May 2020 10:50:44 +0200 schrieb Daniel Kozak:
> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
> Digitalmars-d-announce wrote:
>>
>> As far as I can tell, Walter understands the issues but fundamentally
>> disagrees with pretty much everyone else on the issue.
>
> I do not
On Thursday, 28 May 2020 at 02:47:01 UTC, Jonathan M Davis wrote:
Walter has acknowledged the problem and seems to think that
because it's the programmer's responsibility to deal with
extern(C) functions correctly (since it's not possible for the
compiler to do it), it's up to the programmer
On Thursday, 28 May 2020 at 09:21:09 UTC, Jonathan M Davis wrote:
He did unfortunately manage to convince Atila, so the DIP has
been accepted, but based on the discussions, I think that you
may be the only person I've seen say anything positive about
the DIP treating extern(C) functions as
On Thu, May 28, 2020 at 03:21:09AM -0600, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
> With the DIP in its current state, @safe becomes a lie. The compiler
> no longer guarantees that @safe code is memory safe so long as it
> doesn't call any @trusted code where the programmer
On 28.05.20 10:50, Daniel Kozak wrote:
He seems to think
that weakening @safe is worth doing, because it will ultimately mean that
more code will be treated as @safe and mechnically checked by the compiler,
And I believe he is right.
No, it's a false dichotomy. Weakening @safe to allow more
On Thursday, May 28, 2020 2:50:44 AM MDT Daniel Kozak via Digitalmars-d-
announce wrote:
> On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
>
> Digitalmars-d-announce wrote:
> > As far as I can tell, Walter understands the issues but fundamentally
> > disagrees with pretty much everyone else
On Thu, May 28, 2020 at 4:56 AM Jonathan M Davis via
Digitalmars-d-announce wrote:
>
> As far as I can tell, Walter understands the issues but fundamentally
> disagrees with pretty much everyone else on the issue.
I do not think so, the issue is, that there could be more people who
agree with
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, 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: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 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 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 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 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 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.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 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/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 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 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 example of currently compiling and correctly
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. Post 1028, IIUC, the
compilation will go
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 generally can not be checked. Post
1028, IIUC, the compilation will go
On Tuesday, 26 May 2020 at 22:47:03 UTC, Gregory wrote:
If Walter believed greenwashing was actually a problem, then
the best solution to prevent it would be to not make @safe by
default. If it's not that serious of a problem that he will
push through @safe by default, then greenwashing isn't
On Tuesday, 26 May 2020 at 20:32:13 UTC, Paul Backus wrote:
On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
Which will just lead people to pure @trusted: at the top of
their code to get it to compile again, with or without
extern(C) being @safe by default. Then someone that uses it as
On Tuesday, 26 May 2020 at 20:38:17 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 16:31:57 UTC, 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
On Tuesday, 26 May 2020 at 16:31:57 UTC, 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. Post 1028, IIUC, the
On Tuesday, 26 May 2020 at 17:50:58 UTC, Gregory wrote:
Which will just lead people to pure @trusted: at the top of
their code to get it to compile again, with or without
extern(C) being @safe by default. Then someone that uses it as
dependency will mistaken think it is @safe. What's to stop
On Tuesday, 26 May 2020 at 18:06:00 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC,
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
@safe: the compiler checks
The compiler
On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC,
On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
[...]
The compiler does not and cannot check
On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
[...]
Completely agree but my above says nothing about @trusted.
[...]
Another distinction: pre 1028
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
@safe: the compiler checks
The compiler
On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
@safe: the compiler checks
The compiler does not and cannot check inside @trusted. Whether
or not one
49 matches
Mail list logo
