debugger blues

[Vladimir Panteleev via Digitalmars-d]

On Friday, 25 March 2016 at 05:59:01 UTC, cy wrote:
> * a backtrace that displays when you hit ^C, instead of just 
> silent death

Perhaps have a look at what etc.linux.memoryerror does.

> * DWARF debugging symbols that don't scramble the only program 
> on earth that actually uses them.

What compiler flags did you use?

Having an up-to-date GDB might help.

> * better ways to report program status besides writeln("we got 
> here somehow");

This sort of works:

	try
		throw new Exception(null);
	catch (Exception e)
		context = e.toString().splitLines()[1..$];

A `Thread.getStackTrace` would be nice.

> * catching null pointer errors earlier, instead of waiting 
> until you 1) call the class function and 2) the function 
> accesses a member.

Doesn't this already happen if you compile without -release? 
Calling a class method will invoke the class invariant hidden 
virtual method, which will segfault when looking up the method in 
the vtable.

> * ways to ensure that nothing is being copied, if you 
> accidentally write a wrapper that creates an object instead of 
> referencing it, or moving it.

Structs have this: @disable this(this);

> * it would also be nice to be able to return references, 
> instead of copying structs every time, or writing wrappers 
> around them (which also cannot be used with inout)

You can return by ref...?

> * heap allocated structs, stack allocated classes, it would be 
> nice to have allocation strategy independent from layout 
> strategy.

Heap allocated struct: auto s = new S;
Stack allocated class: auto c = scoped!C;