On Friday, 22 May 2020 at 08:44:10 UTC, Greatsam4sure wrote:
On Thursday, 21 May 2020 at 16:13:57 UTC, zoujiaqing wrote:
Hunt Framework is a full stack Web framework based on DLang
language.
Designed for rapid development of Web servers, similar PHP's
Laravel、Java's Spring、Python's Django!
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
On 24.05.20 10:55, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
...
It's only greenwashing if it's misleading. Putting @safe is a lie,
putting @trusted is honest.
I can't see a practical difference
On 24.05.20 19:44, Arine wrote:
On Sunday, 24 May 2020 at 15:42:54 UTC, ag0aep6g wrote:
[...]
@system does indicate that you don't have to check a function. But its
trumped by other indicators:
[...]
You *have* to check @system code. That's where you are guarantee'd to
have memory safety
On Sunday, 24 May 2020 at 15:42:54 UTC, ag0aep6g wrote:
On Sunday, 24 May 2020 at 14:39:50 UTC, Arine wrote:
Then that is definitely a bug if that's the case. Someone
should probably make a bug report, Walter? If you are still
using @system with @safe, then that would still be somewhere
you
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 declaration safe does not
make it safe.
2. If
On 5/24/20 6:40 AM, Johannes Loher wrote:
Steven actually made a proposal regarding creating 2 different manglings
for extern(C) functions that are implemented in D. Regardless of which
of the solutions is taken, this could provide the same benefits that we
have for extern(D) functions
On Sunday, 24 May 2020 at 12:14:13 UTC, aliak wrote:
On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote:
On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
On Sunday, 24 May 2020 at 14:39:50 UTC, Arine wrote:
[...]
It'd be no different than passing the pointer into @safe code
as a parameter from @system code. Ultimately the error occurs
in @system code and directly as a result of @system code. It is
undefined behavior as well. No amount of safe
On Sunday, 24 May 2020 at 01:26:02 UTC, ag0aep6g wrote:
On 24.05.20 02:55, Arine wrote:
That works even if you make the static this() @safe, and
remove the pointer incrementation.
Sure. `*p = 13;` is perfectly @safe. The static constructor
isn't needed for that part. You can just as well do
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 declaration safe does not
make it safe.
That's why Rust
On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote:
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void whatevs(parameters);
Both require that whatevs() provide a safe interface.
Remember that D has reflection. If we ever
On Sunday, 24 May 2020 at 09:47:37 UTC, Walter Bright wrote:
It's a fair point, but without the source code the distinction
is meaningless.
It's meaningless in terms of what the compiler can check, but
it's not meaningless in terms of documenting the assumptions and
promises the developer is
On Sunday, 24 May 2020 at 11:30:53 UTC, Johannes Loher wrote:
On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
have 2 different defaults.
Is that any more or less
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 declaration safe does not
make it safe.
2. If
On Sunday, 24 May 2020 at 11:25:06 UTC, aliak wrote:
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
have 2 different defaults.
Is that any more or less weirder than having functions inferred
with different attributes
On Sunday, 24 May 2020 at 10:40:11 UTC, Johannes Loher wrote:
does not work). But I admit that it is still a bit weird to
have 2 different defaults.
Is that any more or less weirder than having functions inferred
with different attributes based on context?
On 24.05.20 10:55, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
That's just arguing semantics. Your intended meaning of "greenwashing"
is apparently slightly different from Timon's.
You can call this
On Sunday, 24 May 2020 at 09:47:37 UTC, Walter Bright wrote:
On 5/24/2020 2:29 AM, Panke wrote:
I've always understood that the @safe,@trusted,@system
machinery provides the following guarantee once all holes are
fixed:
If I have a memory corruption in my code than I need to only
look at
On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
I'd like to emphasize:
[..]
Thank you. I do see the picture now. When taking safety
seriously, you would find unannotated declarations and
audit/annotate them. It is not worthy of a compile option. An
average user is, from
On 5/24/2020 2:29 AM, Panke wrote:
I've always understood that the @safe,@trusted,@system machinery provides the
following guarantee once all holes are fixed:
If I have a memory corruption in my code than I need to only look at the
@trusted and @system parts to find it.
Marking whatevs
On Sunday, 24 May 2020 at 08:55:32 UTC, Walter Bright wrote:
I infer your position is the idea that putting @trusted on the
declarations isn't greenwashing, while @safe is.
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void
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 we do, for various reasons. I've seen it a
I infer your position is the idea that putting @trusted on the declarations
isn't greenwashing, while @safe is.
I can't see a practical difference between:
@safe extern (C) void whatevs(parameters);
@trusted extern (C) void whatevs(parameters);
Both require that whatevs() provide a safe
On Sunday, 24 May 2020 at 05:43:45 UTC, Timon Gehr wrote:
@safe is advertised to give mechanical guarantees, where
@trusted is a way for programmers to take responsibility for
parts of the code. It is not advertised to be an unsound linter
with pseudo-pragmatic trade-offs and implicit false
On Sunday, 24 May 2020 at 06:39:27 UTC, Daniel C wrote:
"If you don't use dmd for linking, make sure to add
legacy_stdio_definitions.lib to your command line when linking
against the VS2015 runtime."
Good find. If I was ever aware of that, I had forgotten about it.
Anyway, thanks for
On Sunday, 24 May 2020 at 06:26:56 UTC, Bruce Carneal wrote:
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote:
[snip]
3. Un-annotated declarations are easily detectable in a code
review.
Automating this for the transitive closure of defaulted @safe
functions would help. Maybe
On 24/5/20 5:28, 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 declaration safe does not make it safe.
Here, I agree with Timon: only
On Sunday, 24 May 2020 at 05:15:19 UTC, Mike Parker wrote:
On Sunday, 24 May 2020 at 04:16:10 UTC, Daniel C wrote:
On Saturday, 23 May 2020 at 19:59:51 UTC, Daniel C wrote:
There should be no need to revert to VS 2010. These errors
indicate that something in your build process or setup is
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 declaration safe does not
make it safe.
Agree
32 matches
Mail list logo
