Re: DIP1028 - Rationale for accepting as is
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 multiple
symbols. Only allow `@trusted` to apply to a single symbol. For
IMO, it makes things worse. Because the careless programmer
will slap @trusted to every declaration (maybe with a script or
find/replace macro of his editor). So now, we don't know if the
annotation is greenwashing or careful examination of the
definition.
At least with "@trusted:" and "@trusted { }", the greenwashing
is obvious.
the problem here ist: we are talking about careless programmers.
for those of us who actually care about safety it will be like:
1. ok lets write an extern(c) function.
2. forget to annotate it by accident.
3. hit compile
4. a) get an compiler error the hints that we missed that
annotation
or b) no error at all and we now have silently added unsafe code
to our codebase.
also, you can never trust that an @trusted function is actually
memory safe.
even if it was evaluated in the past. the addition of new code
(and even completely @safe code) can break any assumptions that
@trusted fun was relying on.
so a competent QA team _has_ to either check all @trusted code
fragments.
or with this dip check all @trusted and all extern functions.
Re: DIP1028 - Rationale for accepting as is
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 verified by the compiler. 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 function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise. .di files _could_ just use @trusted instead of @safe. but for extern(D) we could at least add it to the name mangling. it's still not 100% safe, but at least you'd have to work hard to get it wrong.
Re: DIP1028 - Rationale for accepting as is
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, would result in more untrustworthy @trusted code we have to worry about. It's a vicious circle. I try to relax my view on extern annotations. They are @system. We *should* go ahead and diligently mark with @trusted. From experience, it doesn't normally happen. I don't like @safe extern, but it seems like the lesser evil. Walter got a lot of flak. I tried to retrace his thoughts and see the merits. 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.
Re: DIP1028 - Rationale for accepting as 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 incorrect. It's also meaningless. Even if you were to verify the safety of a specific version of your binding, it can't be known what's loaded at runtime. It's not the compiler's concern. @safe extern shall be an error. We might additionally make an exception and make all extern C @system. It would be correct for the declarations, but inconsistent in regard to default safety. It doesn't affect the outcome. Let's say we'll go with @system, it gives us a bit more freedom. We hit compile, our now safe wrappers are errors. We are most likely to do one of two things, depending on the module failing to compile. If it mostly wrappers, we slap @trusted: at the top. If there are just a few functions calling C, we only annotate those with @trusted. Let's be real, we probably won't begin checking and annotating the trustworthiness of the C functions. An individual programmer might, but not on average. We are formally correct, but @trusted can't be trusted at this point. It has lost its meaning. We now have to check all foreign @trusted code, which we probably won't. We could have moved the problem one level down and slapped @trusted: on top of the @system declarations. Now there is a bunch of safe code using them. It doesn't change much. @trusted: is easier to grep, but we won't put everything down and begin trustworthily annotate extern C. So yeah, I do believe Walter was right. @safe on extern is formally incorrect but leads to safer code because @trusted still has its power. 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. the compiler should do it's best to alert you of any mistakes you might make. if the compiler does silently add @safe or @trusted to extern(C) functions you are are to miss annotating it. that is a bad thing for everyone that actually cares about safety. you can't prevent programmers from doing stupid things. but you can at least warn them.
Re: wiki tutorial: D on esp32/esp8266(llvm-xtensa+ldc) and how to get started
On Tuesday, 26 November 2019 at 08:57:49 UTC, dangbinghoo wrote: hi, I just added a simple tutorial to running D betterC on the popular ESP32/esp8266 IoT chip. referenced with the Rust community's Rust on ESP32. https://wiki.dlang.org/D_on_esp32/esp8266(llvm-xtensa%2Bldc)_and_how_to_get_started As esp32 IDF is using newlib as it's libc, the druntime and phobos just simply won't build. But betterC seems working, I didn't do with a very strong test(actually I don't know if there's betterC test case exists), so, just for fun with your own risk! And, Can we do some work to support druntime building against with newlib? If this is true, many MCU would have(newlib supports many MCUs) a `real D` running on it. --- Binghoo Dang I'm also interested in a esp32/esp8266 port of druntime/phobos. If you want to join forces ping me on discord or irc. -Zoadian
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 10:42:33 UTC, Jonathan M Davis wrote: On Thursday, February 22, 2018 10:30:44 psychoticRabboit via Digitalmars-d- announce wrote: On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote: > I'm going to a) never write these imports and b) pretend this > feature doesn't exist. > > Atila what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution. Honestly, I'm against importing multiple modules on a single line just like I'm against putting multiple variable declarations on a single line. They're harder to read and easier to screw up. - Jonathan M Davis +1 I agree 100%
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Please report your CPU (GitHub/Gist): my results for Intel Core i7-6700K CPU @ 4.00GHz rev.2 (the one with sgx) https://gist.github.com/Zoadian/f53d818e714a849ba7f34bbec2f3339a awesome!
Re: Logo for D
On Monday, 18 January 2016 at 22:48:52 UTC, Brad Anderson wrote: Doesn't it look so much better: http://i.imgur.com/QlrbCou.png +1
Re: 2D game engine written in D is in progress
On Tuesday, 3 February 2015 at 16:30:27 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/VDP-engine Alpha release. Very basic functionality at the moment, will be expanded later. had a quick look: public class Color This is probably going to be slow. you want to read about 'cache friendliness'. And for a game/graphics engine also google 'data oriented design'.
