Re: dlang.org redesign -- the state of documentation and learning resources [part 2]

[Jerry Morrison via Digitalmars-d]

After spending hours and hours in a breadth-first scan to learn 
me a D, I agree completely with the suggestions in this thread 
and I'm happy to help implement them.


Caveats: I'm just now coming up to speed on D and I'm an 
engineer, not a tech writer.


I think the biggest needs are:

(1) Improve the home page "Why pick D?" info. The current text 
doesn't quite answer. Why switch from your creaky old language? 
And if you're switching, why D vs. Rust?


Mention the game-changing plans for optional GC, memory safety, 
and calling C++. Then D becomes a clear win in real-time, 
safety-critical, and security-critical systems.


(2) Add an introduction for experienced C++/Java programmers. Get 
them up to speed quickly and excited about how D is easier, 
faster, more fun, more reliable, and un-fsck'd up.


(3) [Easy] Add comparative info to the links to available books, 
including the D reference: Aim? Audience? Up to date? Coverage?


Ali's ebook is very nice but for beginning programmers, not me. 
(Ali, you might want to say so up front.) Andrei's book is 4.6 
years old. How much has D changed? Honestly I'm a slow reader and 
will eventually read the spec, so I started reading that. Is that 
a rough way to start? Too many forward references? Too abstract? 
What'll I miss by not reading a book first (besides Andrei's 
humor)?


*If y'all shed light on the books, I'll update the wiki* 
http://wiki.dlang.org/Books


Note: This page doesn't jive with 
http://digitalmars.com/d/dlinks.html


(4) [Easy] Add more info on the available IDEs: Up to date? 
Graphical debugger? Features? Maintained? Recommended?


I'm currently using Sublime text but need my graphical debugger 
so I'll try Eclipse + DDT soon. I could try Visual D but I'm 
expecting to move off Windows. A good IntelliJ plug-in would be 
ideal.


*Tell me about the IDEs and I'll update the wiki* 
http://wiki.dlang.org/IDEs



On Saturday, 24 January 2015 at 04:35:27 UTC, weaselcat wrote:

you mean like this?
https://qznc.github.io/d-tut/index.html


Sort of, but it's old and says little about the language itself.

Re: forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

This is the first I've heard that allocating GC memory in a 
destructor will crash. That's an unexpected gotcha. I'd expect to 
be able to reliably do I/O or throw an exception.


Strategy 1. Fix the GC's limitation. (One fewer pitfall to 
baby-sit.)


Strategy 2. Have the compiler inform the programmer. (The 
compiler can't catch all bugs but it should do what it can. 
Arguably this is a GC bug, not mine.)


Strategy 3. Put bold warnings in the reference 
 and all tutorials. 
That's useful but insufficient. Programmers will carry 
assumptions from other programming languages. Even those who read 
the D reference won't all remember that detail when it matters.


Strategy 4. Accept such crashes. (No good. The D home page 
promises safety.)



On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim Grøstad 
wrote:
If the classes are written for RAII then the destructors have 
to be called in reverse order of the constructors. IIRC D does 
not guarantee this when you use the GC.


So to do it right there is a lot of GC overhead.


Yes, but the usability question is what do programmers expect? 
How much do they assume before turning to the docs?


It's a big stretch to expect LIFO behavior from garbage 
collection. It's not a stretch to expect logging to work.

Re: forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven 
Schveighoffer wrote:
Actually there's nothing on the documentation about class 
destructors
[1] that warns about that specific issue of the current (and 
default) GC.


[1] http://dlang.org/class.html#destructors



I think the docs are in need of updating there. It's not meant 
to be a secret that you cannot allocate inside a GC collection. 
I'll try to put together a PR.


Please do!

On Thursday, 22 January 2015 at 14:07:31 UTC, Steven 
Schveighoffer wrote:
In the vast majority of cases, nobody adds a dtor, or they use 
dtors for their intended purpose (deallocating non-GC 
resources) and everything works fine. And the runtime catches 
any slips with an appropriate handling (abort instead of 
corrupt memory).


While you're writing that PR, would you clarify that "The 
destructor is expected to release any resources held by the 
object." means ***non-GC resources*** and that `new` will abort?


Also would you be so kind as to make a bolder warning that member 
refs to GC objects may be invalid? That's nasty and unexpected! 
(Java finalizers don't work like that.) [Nulling them out would 
be nicer for debugging...]


"This means that destructors cannot reference sub objects. This 
rule does not apply to auto objects or objects deleted with the 
DeleteExpression, as the destructor is not being run by the 
garbage collector, meaning all references are valid."


That wording contradicts the previous paragraph about "the delete 
expression ... [calls] ... the garbage collector calls the 
destructor immediately". Maybe something like "...not being run 
in a garbage collection..." would be better.

Re: forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

On Tuesday, 27 January 2015 at 22:46:30 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison 
wrote:
On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim 
Grøstad wrote:
If the classes are written for RAII then the destructors have 
to be called in reverse order of the constructors. IIRC D 
does not guarantee this when you use the GC.


So to do it right there is a lot of GC overhead.


Yes, but the usability question is what do programmers expect? 
How much do they assume before turning to the docs?


Unfortunately, I think D is now entrenched in Java/C#ish 
expectations. Which is no good, since the main advantage D can 
have over those languages is to restrict the language semantics 
to a level where D has an inherent performance (timeliness) 
advantage.


My expectations from a GC in a system level programming 
language would be to give max priority to fast collection at 
the expense of features (lean and mean).


It's a big stretch to expect LIFO behavior from garbage 
collection. It's not a stretch to expect logging to work.


What does logging in a destructor tell you? The destructor 
might not execute until the program terminates.


Logging might help with debugging, say, to log accumulated data 
before the object disappears. Perhaps it's not a great example, 
but since logging doesn't do anything dubious like forging a 
strong link to the object, it would seem safe at first 
expectation.


Because of this unknown delay before GC collection, also because 
GC can collect a cycle of objects, we know it can't promise LIFO 
order.


You might not expect LIFO from the GC, but can you trust 
library authors to ensure that it does assume LIFO when manual 
memory management becomes commonplace?


Sorry, I don't understand the question. I expect LIFO for freeing 
structs on the stack.


D needs to define what it means by "safe" and "convenient". It 
is currently very much up in there air when it applies and when 
it does not.


Yes.

The forum discussion 
http://forum.dlang.org/thread/gvaacvczsrybguddo...@forum.dlang.org?page=1 
deals with an InvalidMemoryOperationError. Vladimir Panteleev 
created a wiki page 
http://wiki.dlang.org/InvalidMemoryOperationError on how to debug 
such cases, starting with building a patched Druntime. Very 
helpful, but not easy.


==> It would be a big step forwards if the runtime printed a 
clear error message like: "Attempt to allocate GC memory within 
the destructor for class Foo."

Re: forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

From the forum thread 
http://forum.dlang.org/thread/ossuvfmqthllgdpgz...@forum.dlang.org?page=1


and the PR 
https://github.com/D-Programming-Language/dlang.org/pull/851


I learned that allocation in a destructor isn't the only crash 
case here.


The GC calls a class instance's invariant() method during a 
collection cycle, before calling the object's destructor, and 
possibly after destructing objects it references. So if the 
invariant() touches any of its member references, it can crash!


A solution to that would be to never call invariants during a 
collection cycle, but what other gotcha's exist during 
collection? Would @nogc on class destructors help them?

Re: forcing "@nogc" on class destructors

[Jerry Morrison via Digitalmars-d]

On Wednesday, 28 January 2015 at 11:32:26 UTC, Ola Fosheim 
Grøstad wrote:
But I think GC and destructors are not a good match... so I 
would personally go for performance and no destructors.


Yes. That is the bottom line.

A good match for GC is the phantom reference, which notifies you 
when an object gets collected with no way to resurrect the 
collected object or access its instance variables.