Re: Hunt Framework 3.1.0 Released, Web Framework for DLang!
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!
## This major update is as follows:
1. safety - related GET parameter test
2. improve the worker thread, add WokerGroup Modularization
3. the underlying library Stability IO
4. improved Windows platform
## Parameter Check Example Code:
```D
classUserController : Controller
{
...
@Actionstring user(@Min(1) uint id)
{
auto result = request.valid();
if (!result.isValid())
{
string[string] messages = result.messages();
// error
}
return null;
}
}
```
A holistic tutorial will help this framework more. The docs are
not helpful to me. This is the reason people use vibe because
of the better docs, tutorial, and book
Thanks watch Hunt Framework! There will be document output next
month.
Re: DIP1028 - Rationale for accepting as is
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 dependencies whatever default applies. That's the theory. But we do, for various reasons. I've seen it a lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way. We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly. Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing. Yes, it would be a big nuisance. Absent a change in the DIP the safety conscious who want to continue with D will try to back out the compiler lies as best they can: additional tooling, additional code review strictures, selective rewrites, ... Not sure how that unfortunate future would play out exactly but it would not be pretty. Much much better to fix the DIP.
Re: DIP1028 - Rationale for accepting as is
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 we do, for various reasons. I've seen it a lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way. We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly. Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing.
Re: DIP1028 - Rationale for accepting as is
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 between: @safe extern (C) void whatevs(parameters); @trusted extern (C) void whatevs(parameters); Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user. Sure, that's the point. Your @safe by default DIP in practice makes certain declarations @trusted by default. @safe is a fine default. @trusted is a horrible default. That's why your DIP claims it is for @safe by default (and not @trusted by default). Except in this one weird special case, where it introduces @trusted by default.
Re: DIP1028 - Rationale for accepting as is
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 issues. If you are ignoring @system code because you think @safe code doesn't interact with it at all, then that's a problem you are creating for yourself. @system code can still call @safe code, and that @system code that is calling the @safe code can pass invalid information that causes the @safe code to misbehave. You have to check @system for memory safety issues. You're right; it's not accurate that "@system does indicate that you don't have to check a function". That's only true under particular conditions: When your entry points are @safe and you have already verified all @trusted functions (including their call graphs which might include @system functions), then you can ignore any other @system functions, because your program doesn't call them anyway. But that's true for any function. If your program doesn't call it, you don't need to check it. So it's not a particularly meaningful thing to say about @system, and that's on me.
Re: DIP1028 - Rationale for accepting as is
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 have to look for not memory safe code. @trusted should just mean that someone verified it. @system then would mean no one's verified it to be safe, that doesn't mean you don't have to check it. @system does indicate that you don't have to check a function. But its trumped by other indicators: * @system entry points (`main`, static constructors, static initializers) - have to check those. * Foreign prototypes (`extern (C)` and friends) - have to check those, whether they're @system or @safe or @trusted. * @system functions that are being called by @trusted ones - have to check those. But I would say that's part of verifying @trusted functions. Other than that (and maybe other special cases that I've missed), you can safely ignore @system functions, because your @safe program cannot possibly be calling them. You *have* to check @system code. That's where you are guarantee'd to have memory safety issues. If you are ignoring @system code because you think @safe code doesn't interact with it at all, then that's a problem you are creating for yourself. @system code can still call @safe code, and that @system code that is calling the @safe code can pass invalid information that causes the @safe code to misbehave. You have to check @system for memory safety issues. It seems Walter's comments about only have to review @trusted are being taken too literally.
Re: DIP1028 - Rationale for accepting as 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. 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. 3. Un-annotated declarations are easily detectable in a code review. [...] 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 already been reviewed, committed, and published under the assumption of @system-by-default. Those declarations need to be flagged for re-review in order to avoid introducing silent safety violations to existing D projects. To address this issue, I'm working on a PR to have dmd emit a diagnostic message when it encounters an un-annotated external function declaration. Feel free to drop by and comment: https://github.com/dlang/dmd/pull/11176
Re: DIP1028 - Rationale for accepting as is
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 (linker errors if @safety does not match in the mangling). However, it sounds like a complicated solution (in an answer to him, you already mentioned that there might be technical difficulties regarding some object formats, debugging symbols, etc.) and I am not sure it's worth it. It also makes swapping out the libraries a bit weird: if you use an actual C library, it will always link but if swap to a library implemented in D, it only links if the @saftey mangling matches. I don't think the technical difficulties make it impossible. If you can't point at the same address, point at a noop/jmp before the real address. This isn't hard. In terms of actual C libraries, only the unsafe symbol will be defined (naturally), so marking the extern(C) function @safe (or assuming it's safe by default) is going to fail to link. Note that "linker errors if @safety does not match" is not entirely accurate. This is ONLY the case if the prototype is @safe and the implementation is not. In all other cases, the program will link. Next, I'd say that linker errors are reasonable for C functions -- they are not mangled, so the name is obvious (for extern(C) safe functions I would propose a really simple mangling like _d_safe_functionname). Plus, users who declare extern(C) prototypes already have to deal with linker errors because they have to name their prototypes correctly. But I don't anticipate anyone taking up this idea (I lack the skills), it already seems DOA based on Walter's position. -Steve
Re: DIP1028 - Rationale for accepting as is
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 have 2 different defaults. Is that any more or less weirder than having functions inferred with different attributes based on context? What exactly are you referring to? Attribute inference by D, specifically template functions. The attributes are inferred based on context (I don't know the exact algorithm). So a function f(T)(T) when called can maybe be pure, maybe safe, maybe not? From what I understand, it does not depend on the context but on the template parameters you pass to the template. I agree that it might be a bit confusing at first, but it makes sense if you realize that templates themselves are not functions but something that can generate functions (and other constructs) from compile time parameters. Why shouldn't the attributes of a generated function be able to depend on the parameters being passed to the template? Basically everything else can depend on them, too. Automatically inferring the attributes is just a very convenient way to do that. But yeah, it's not 100% consistent that they are not also inferred for regular functions (some people have been arguing for that). However, at least for templates, there is a very good reason for the difference (or at least the fact that attributes are inferred for templates): if that was not the case, it would basically be impossible to write generic code that works with all the attribute combinations. However, the very purpose of templates is to enable writing generic code. They wouldn't make that much sense if that capability was strongly limited. On the other hand, having different @safety defaults for bodiless function declarations and regular faction declarations does not have such a big benefit, especially when considering the fact, that we can have the same defaults but make @safe (default or explicit) bodiless function declarations a compiler error. If we ignore that option for some reason, it would only be dort of a necessity in order to prevent people from shooting them selves in the foot without even noticing. But there is no inherent value in the difference, it doesn't enable anything. That said, I'd still prefer this variant over what DIP1028 does currently. It's just that I think the other option is even better because it is more consistent.
Re: DIP1028 - Rationale for accepting as is
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 code can save you from that. I think you're arguing against a point that wasn't made. I'm not saying that there's anything fundamentally unsound about an @system static constructor. As you say, it's the same any other @system function. I'm just saying that it's another thing you have to check when you want to verify that a program is actually safe. [...] 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 have to look for not memory safe code. @trusted should just mean that someone verified it. @system then would mean no one's verified it to be safe, that doesn't mean you don't have to check it. @system does indicate that you don't have to check a function. But its trumped by other indicators: * @system entry points (`main`, static constructors, static initializers) - have to check those. * Foreign prototypes (`extern (C)` and friends) - have to check those, whether they're @system or @safe or @trusted. * @system functions that are being called by @trusted ones - have to check those. But I would say that's part of verifying @trusted functions. Other than that (and maybe other special cases that I've missed), you can safely ignore @system functions, because your @safe program cannot possibly be calling them.
Re: DIP1028 - Rationale for accepting as is
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 the assignment in `main`. The static constructor is another feature that can smuggle unsafe code (the increment) into your program without the @trusted warning label. 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 code can save you from that. You'd have to make the p initialization @safe. @safe: int* p = cast(int*) // error But note this doesn't work: @safe int* p = cast(int*) // compiles Having the default become @safe will help detect this, as I don't imagine that is a whole lot of usage of @safe: to begin with. The example compiles with `-preview=safedefault`. And even if that gets changed, it will probably still compile when marked @system. So we still won't find it when looking for "@trusted". 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 have to look for not memory safe code. @trusted should just mean that someone verified it. @system then would mean no one's verified it to be safe, that doesn't mean you don't have to check it.
Re: DIP1028 - Rationale for accepting as 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. That's why Rust has gotten rid of declarations all together, except for C, which are implicitly marked unsafe, and they cannot be marked "safe" (there is no such feature). 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. Having extern(C) be @safe by default doesn't stop greenwashing. As others have pointed out, you are doing the greenwashing for the programmer. That's not better. 3. Un-annotated declarations are easily detectable in a code review. Declarations annotated with @trusted are even easier to detect. And arguably declarations that aren't annotated aren't that easy to detect. 4. Greenwashing is not easily detectable in a code review. 5. Greenwashing doesn't fix anything. The code is not safer. It's an illusion, not a guarantee. 6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to. Hence it's more likely to be correct than when greenwashed. 7. D should *not* make it worthwhile for people to greenwash code. It is, in a not-at-all obvious way, safer for C declarations to default to being safe. This whole situation just makes it more obvious to me, you shouldn't be able to mark extern(C) declarations as @safe or @trusted at all. If that truly is your fear, it should just not be possible to mark them as @safe/@trusted. 8. D should make incorrect code *more* difficult, not easier. Or are you conveniently ignoring this ideology? Code is going to break no matter what. That's the cost you are going to pay for making @safe default. You can't fix that. The difference is what the aftermath will look like.
Re: DIP1028 - Rationale for accepting as is
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 do a reflection check on these, @trusted stands out better there than @safe. Of course it could also just return null in reflection meaning "default applied" and that could be detected as well. Otherwise it is the same, yes, but this reflection thing is a small nice benefit.
Re: DIP1028 - Rationale for accepting as is
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 making.
Re: DIP1028 - Rationale for accepting as 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 weirder than having functions inferred with different attributes based on context? What exactly are you referring to? Attribute inference by D, specifically template functions. The attributes are inferred based on context (I don't know the exact algorithm). So a function f(T)(T) when called can maybe be pure, maybe safe, maybe not?
Re: DIP1028 - Rationale for accepting as 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. 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. 3. Un-annotated declarations are easily detectable in a code review. 4. Greenwashing is not easily detectable in a code review. 5. Greenwashing doesn't fix anything. The code is not safer. It's an illusion, not a guarantee. 6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to. Hence it's more likely to be correct than when greenwashed. 7. D should *not* make it worthwhile for people to greenwash code. It is, in a not-at-all obvious way, safer for C declarations to default to being safe. Apparently, you're of the opinion it's better the compiler does the greenwashing. Got it!
Re: DIP1028 - Rationale for accepting as is
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 based on context? What exactly are you referring to?
Re: DIP1028 - Rationale for accepting as is
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?
Re: DIP1028 - Rationale for accepting as is
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 greenwashing: @trusted extern (C) void whatevs(parameters); And this: @safe extern (C) void whatevs(parameters); And then you must also call this greenwashing when compiled with `-preview=safedefault`: extern (C) void whatevs(parameters); They all do the same thing. But the first one is the most preferable form, because it shows up when you search for "@trusted" which is our "here be dragons" sign. The second one should be deprecated in favor of the first one. That would move us one baby step closer to the ideal: "@safe code is memory safe, unless someone made a mistake with @trusted." The third one moves us one step further away from that ideal. That's the wrong direction. It's greenwashing by default. And since greenwashing is bad, greenwashing by default means bad by default.
Re: DIP1028 - Rationale for accepting as is
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 the @trusted and @system parts to find it. Marking whatevs @safe violates this, marking it @trusted does not. It's a fair point, but without the source code the distinction is meaningless. The distinction is that you can find a slapped on trusted with a grep. Rather than valgrind.
Re: DIP1028 - Rationale for accepting as is
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 whatevs(parameters); Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user. From my perspective, there is a clear difference in meaning between them: @safe means verified by the compiler (which as you mentioned can never be true for declarations where the code is not available, hence it always is a lie in that case) and @trusted means verified by the developer. Whenever @trusted is slapped on _anything_, it is clear that extra caution is needed (in codereviews etc.) and as others have mentioned, it is easily searchable. When I put @safe on a piece of code, my expectation is that it is actually verified by the compiler. If that is not possible, it should not compile. The same reasoning also applies to the case where the annotations are not added by the developer explicitly and the defaults are used instead: If the default is @safe and the code for an unannotated declaration is not available, it should not compile. Making @trusted the default is not an option because as mentioned earlier, one of the points of @trusted is for it to be actually seen, which is not the case if it is the default, so I will not elaborate on that. If @sytem is the default, there is no issue but of course the whole point of this DIP is to move away from that. I understand that today it is possible to slap @safe on declarations without code without the compiler complaining but it really _should_ be an error in order to have a consistent meaning of @safe, @trusted and @system (@safe = compiler verified, @trusted = user verified, @system = not verified) also in the case of declarations where no code is available. Let's assume this is indeed the way to go, then there are 2 possible solutions for this DIP regarding how to handle this: 1. Make declarations without code default to @system instead of @safe. This is what many here have been arguing for but as you mentioned several times, it has the drawback of adding special cases to the language. As a user, it does not seem that problematic though because the compiler can easily tell you what is going on when there is an issue (i.e. calling an unannotated declaration without code from a @safe function could result in compiler error message that explains why this does not work). But I admit that it is still a bit weird to have 2 different defaults. Additionally, explicitly annotating such declarations with @safe should be a compile error. 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 or @trusted is now mandatory. This is what Timon has been arguing for if I understood him correctly. 3. There may be a third option if we introduce something like conditional safety but I do not completely understand that yet. This is what H.S. Theo has been suggesting. Option 1 and 2 both have the „issue“ that people might „greenwash“ things by simply slapping @trusted: at the top of a file. But that can always be done anyways and at least it is explicit and searchable. As mentioned, using @trusted now has the meaning that it is user verified so it always needs extra caution. Personally I prefer option 2 because it is a lot more consistent: There are no special cases. Until now, I did not discuss whether or not all of this should apply only to extern(C) function declarations without code or all function declarations without code. This is because it is a separate point. Both are possible and have pros and cons: If it applies to extern(C) function declarations without code only, then we can still have @safe extern(D) declarations. They are not verified by the compiler but you get linker errors instead because @safe is part of the mangling. The benefit is that you get more @safe code by default, the drawback is that it relies on linker errors instead of compiler errors and that it introduces a special case. If it applies to all function declarations without code, also extern(D) function declarations without bodies need to be annotated with @trusted explicitly if they are @safe or @trusted. If they are @system, we still get linker errors due to name mangling. The benefit is that it is a very consistent solution, no special cases are needed. The drawback is that it requires more manual effort to add the additional annotations (but then, don't we want to encourage
Re: DIP1028 - Rationale for accepting as is
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 experience, worse off with extern being implicitly @system.
Re: DIP1028 - Rationale for accepting as is
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 @safe violates this, marking it @trusted does not. It's a fair point, but without the source code the distinction is meaningless.
Re: DIP1028 - Rationale for accepting as is
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 whatevs(parameters); Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user. 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 @safe violates this, marking it @trusted does not.
Re: DIP1028 - Rationale for accepting as is
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 lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way. We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly.
Re: DIP1028 - Rationale for accepting as is
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 interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user.
Re: DIP1028 - Rationale for accepting as is
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 negatives. And turns back to my previous question, that Walter (or Atila) never replied: what I need to reply back to customers asking us about @safe. @safe is for mechanical check or not? An official and public declaration please. /P
Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers
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 your help Mike! Without it I may have given up on D for another year or so ;-) Glad I could help!
Re: DIP1028 - Rationale for accepting as is
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 that capability is there already and I missed it? This tooling up to try and mitigate the damage caused by the DIP would not be necessary were Timon's model followed. After reading Timon's latest I've regained hope that this could still work out well.
Re: DIP1028 - Rationale for accepting as is
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 @system and @trusted should be possible,
and in my personal view it should be mandatory to annotate external
declarations. If not, at least default to `@system`.
2. If un-annotated declarations cause a compile time error, it is highly
likely the programmer will resort to "greenwashing" - just slapping
@safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've
all done it. Sometimes even for good reasons.
So the compiler helpfully does the "greenwashing" for us. How is that an
improvement in any way?
3. Un-annotated declarations are easily detectable in a code review.
No, they are not. If somebody slaps `@trusted:` at the beginning of a
file, that's a conscious decision, there will be a commit for that.
Fingers can be pointed and questions asked.
If the compiler silently does it's highly likely that many people won't
notice, and at the very least there will be plausible deniability
("sure, boss, I didn't know you had to slap `@system` to our C
declarations, also, I was using @safe and the compiler didn't complain").
4. Greenwashing is not easily detectable in a code review.
I would say that greping for `@trusted:` is no that hard. I'm pretty
sure tools like d-scanner are more than able to catch the more advanced
cases.
5. Greenwashing doesn't fix anything. The code is not safer. It's an
illusion, not a guarantee.
Yet the compiler will just do it, breaking all the promises for `@safe`
code in the process. Now the whole `@safe` concept becomes the same
"illusion".
6. If someone cares to annotate declarations, it means he has at least
thought about it, because he doesn't need to. Hence it's more likely to
be correct than when greenwashed.
Q.E.D.
How come this doesn't apply to the compiler?
7. D should *not* make it worthwhile for people to greenwash code.
Then just disallow blanket greenwashing at all. You're just making the
case for forbidding `@trusted:`, and that's something I'd totally support.
Or make it so that function declarations need
It is, in a not-at-all obvious way, safer for C declarations to default
to being safe.
It's definitely one of most not-obvious things I've ever seen here.
Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers
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 borked. Have you tried building your app with dub and using bindbc-sdl as a dependency rather than doing it separately DMD? This way, you can ensure that everything is being compiled with the same options and the linker is getting the correct libraries. I figured it out by going through the changelog for the compiler. From "Change Log: 2.069.0" @ https://dlang.org/changelog/2.069.0.html#link-against-vs2015 "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." Adding legacy_stdio_definitions.lib fixed that last problem. The 64-bit build is working as well.. I had mistakenly put the wrong DLL alongside it *facepalm*. It's using the default linker for 64-bit though, so I'll need to try with the Visual Studio linker. Now that I've figured out the rest, I think it should be trivial though. Obviously the legacy_stdio_definitions.lib file needs to be documented somewhere on this site other than on a changelog. I will probably use dub for projects in the future, but I wanted a quick compilation option for building single-file programs without the extra setup and structure dub entails. Anyway, thanks for your help Mike! Without it I may have given up on D for another year or so ;-)
Re: DIP1028 - Rationale for accepting as 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 completely. Not in dispute that I've seen. In the same vein, defaulting a declaration to @safe doesn't make it safe. For the ultra paranoid, even the name mangling in D libraries is not to be trusted because "the implementation is not available". 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. 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. 3. Un-annotated declarations are easily detectable in a code review. Automating this for the transitive closure of defaulted @safe functions would help. Maybe that capability is there already and I missed it? [snip] It is, in a not-at-all obvious way, safer for C declarations to default to being safe. I agree that it is not-at-all obvious. On a positive note, the DIP discussion/clarification should encourage the safety conscious to rebase code to a machine checkable form whenever feasible.
