Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 23:42:58 UTC, Dukc wrote: I don't understand this part. If an assert was failing, the program is going to terminate anyway, so InvalidMemoryOperationError is no problem. Well, it might obfuscate the underlying error if there is no stack trace, but banning `assert`ing in anything that could be called by a destructor sounds too drastic to me. Even the lowest level system code tends to contain asserts in D, at least in my codebase. If asserting is banned, destructors can do faily much nothing. I'd think it's much more practical to redefine the assert failure handler if InvalidMemoryOperationError due to a failed assert is a problem. Yes, this can be worked around. Passing -checkaction=C to the compiler will use the C assert handler and no exception will be thrown (which, IMO, should be the default behavior of asserts anyway). But even then, I believe as a general rule that any code which touches an assert has no place in a finalizer. And that's because asserts are inherently deterministic. A properly-written assert is used to verify an expectation that the program is in a specific state at a specific point in its execution. If the program is not in that state at that point, then we know we've got an error in our code. It's because of this determinism that we can remove asserts from released code and expect that nothing will break, and it's why we don't assert on conditions that are beyond our control (like user input). Because finalizers are non-deterministic, they kill that "at a specific point in the program's execution" part, rendering any asserts they touch unreliable. It is realistically possible that an assert invoked in a finalizer never triggers during development, then the program is released with asserts removed, and then it breaks out in the wild because a finalizer is invoked at a point when the program isn't in the expected state. This doesn't make *destructors* useless, but *finalizers* really are mostly useless most of the time, IMO. As D programmers, we need to consciously be aware of the distinction since the language isn't.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thu, Mar 04, 2021 at 11:42:58PM +, Dukc via Digitalmars-d-announce wrote: > On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: [...] > If an assert was failing, the program is going to terminate anyway, so > InvalidMemoryOperationError is no problem. Well, it might obfuscate > the underlying error if there is no stack trace, but banning > `assert`ing in anything that could be called by a destructor sounds > too drastic to me. Even the lowest level system code tends to contain > asserts in D, at least in my codebase. If asserting is banned, > destructors can do faily much nothing. I'd think it's much more > practical to redefine the assert failure handler if > InvalidMemoryOperationError due to a failed assert is a problem. This is precisely why Walter (and others) have said that assert failures should not throw anything, they should simply terminate (perhaps calling a user-defined panic function right before aborting, if special handling is needed). That, or we take Mike's advice to pretend that class dtors don't exist. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ "Some examples: attempting to index an associative array can trigger an attempt to allocate a RangeError if the key is not present; a failed assert will result in allocation of an AssertError; calling any function not annotated with @nogc means GC operations are always possible in the call stack. These and any such operations should be avoided in the destructors of GC-managed objects." I don't understand this part. If an assert was failing, the program is going to terminate anyway, so InvalidMemoryOperationError is no problem. Well, it might obfuscate the underlying error if there is no stack trace, but banning `assert`ing in anything that could be called by a destructor sounds too drastic to me. Even the lowest level system code tends to contain asserts in D, at least in my codebase. If asserting is banned, destructors can do faily much nothing. I'd think it's much more practical to redefine the assert failure handler if InvalidMemoryOperationError due to a failed assert is a problem.
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 17:18:38 UTC, Bastiaan Veelo wrote:
On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote:
[...]
It already does this, I would say.
1. The D equivalent of your use of `#if ... #else ... #endif`
is `version() {...} else {...}`, which works in VisualD the
same way as you show. `static if` is different: the condition
often depends on the value of template parameters, so this does
not simply translate to "dead" or "alive" in every case.
2. typeid is a runtime concept (takes inheritance into account)
so this won't work in an editor outside of a debugging session.
However VisualD already shows the (static) type and scope of
variables on mouse-over, which is all you can wish for, I think.
-- Bastiaan.
Oh, maybe Visual D has been updated with it lately? When I made
the gif (some months ago?) you can see that no type information
is available.
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote:
On Thursday, 4 March 2021 at 13:29:11 UTC, Imperatorn wrote:
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze
wrote:
[...]
A few questions.
How hard would the following be:
1. Highlight code as dead or alive in static if
2. Show typeid when hovering over a variable
I have gifs showing what I mean. I'll post them when I get
back to my laptop.
https://filebin.net/19gupoeedfdjx5tx
One GIF is the behaviour in C# I would like to have in D as
well with static if, and the other is displaying typeid on
hover.
It already does this, I would say.
1. The D equivalent of your use of `#if ... #else ... #endif` is
`version() {...} else {...}`, which works in VisualD the same way
as you show. `static if` is different: the condition often
depends on the value of template parameters, so this does not
simply translate to "dead" or "alive" in every case.
2. typeid is a runtime concept (takes inheritance into account)
so this won't work in an editor outside of a debugging session.
However VisualD already shows the (static) type and scope of
variables on mouse-over, which is all you can wish for, I think.
-- Bastiaan.
On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
This post is 3+ years overdue. I initially put it off for the lack of a purpose-built tool in the language or the library to distinguish between normal destruction and finalization (when the GC is invoked by the destructor). After we got the `GC.inFinalizer` thing and having made a few stalled attempts to get the thing written, I finally sat down a couple of weeks ago and forced myself to finish it. The result is not what I had originally intended, as the topic turned out to be much more involved than I had realized. What was supposed to be one post very quickly became two, and now it looks like there will be at least four before I'm done. (I didn't even get to the GC.inFinalizer thing in this first post.) Object destruction in D has dark corners that I had never knew existed until recently, and I expect that as I experiment with them and talk with some battle-hardened warriors like Adam, I'll find myself with many more words to write on the topic. The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ Reddit: https://www.reddit.com/r/programming/comments/lxkcxp/symphony_of_destruction_structs_classes_and_the/ The GC series to date: https://dlang.org/blog/the-gc-series/
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 13:29:11 UTC, Imperatorn wrote: On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: [...] A few questions. How hard would the following be: 1. Highlight code as dead or alive in static if 2. Show typeid when hovering over a variable I have gifs showing what I mean. I'll post them when I get back to my laptop. https://filebin.net/19gupoeedfdjx5tx One GIF is the behaviour in C# I would like to have in D as well with static if, and the other is displaying typeid on hover.
Re: Visual D 1.1.0 released
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: Hi, development on Visual D, the Visual Studio extension that adds D language support to VS 2008-2019, has been rather slow recently, but finally the results of recent months have been released. Some highlights of this new version: - semantic engine updated to frontend 2.095.1 - adds "adornments" (Visual Studio terminology) to the call site of parameters that are passed by (mutable) ref, out or lazy. See https://rainers.github.io/visuald/visuald/images/parameterstorage.png for some examples. - integrates dfmt for command "Format Document" See https://rainers.github.io/visuald/visuald/VersionHistory.html for a full list of changes. You can find the update installer or a full installer bundled with latest versions of DMD and LDC here: https://rainers.github.io/visuald/visuald/StartPage.html Cheers, Rainer Hi, I've gotten D articles to the frontpage of Hacker News 4 times. I think this would be a good candidate to get to the frontpage of Hacker News again. I want you to submit it to Hacker News, then add a comment saying: * Explain why you made this * Explain what's interesting about Visual D * Offer to explain questions Use the title: "Visual Studio Code for D Language 1.1.0"
Re: Visual D 1.1.0 released
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: Hi, development on Visual D, the Visual Studio extension that adds D language support to VS 2008-2019, has been rather slow recently, but finally the results of recent months have been released. Some highlights of this new version: - semantic engine updated to frontend 2.095.1 - adds "adornments" (Visual Studio terminology) to the call site of parameters that are passed by (mutable) ref, out or lazy. See https://rainers.github.io/visuald/visuald/images/parameterstorage.png for some examples. - integrates dfmt for command "Format Document" See https://rainers.github.io/visuald/visuald/VersionHistory.html for a full list of changes. You can find the update installer or a full installer bundled with latest versions of DMD and LDC here: https://rainers.github.io/visuald/visuald/StartPage.html Cheers, Rainer A few questions. How hard would the following be: 1. Highlight code as dead or alive in static if 2. Show typeid when hovering over a variable I have gifs showing what I mean. I'll post them when I get back to my laptop.
