Hacker News Reader

Comment by yokohummer7 | Hacker News Reader

> Implicit numeric casts that lose bits are not allowed anymore.

That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level.

> ??

Sorry if my understandings or my words were wrong, but I got the impression that D also suffers from destructors that throw. (double-throw) Is this not the case in D? If so, could you elaborate how it achieves that?

I'm personally rather fond of purging exceptions from the language level completely, like Go did(Of course panics are technically exceptions, but their usage is culturally discouraged). Of course, this is just my personal opinion, but I would be happy if D had a story on this problem.

View on HN

Concerning exceptions, I personally hate how Go implemented their error handling. This Quora answer explains it perfectly: https://www.quora.com/Do-you-feel-that-golang-is-ugly

Not that I'm a huge fan of exceptions either, but Go is definitely not a reference when it comes to error handling. My personal favorite, by far, is still CL's condition system.

Still, I've never had any issues with exceptions in D. Even exceptions thrown in destructors will raise a core.exception.FinalizeError with all the relevant information attached to it.

I've worked on large (1M+ LoCs) C++ codebases with exceptions disabled. Threading error codes all over the place, everywhere, is not pretty. Someone always forgets a check somewhere and you then spend 2 weeks figuring out why it crashes. It also pollutes the instruction stream with branches all over the place.

D also has assertions, unittests, preconditions, postconditions and invariants built into the language.

Also, unless there's actually an exception raised, frame handlers are faster than return code checks (its implemented as 3 MOV instructions per try block instead of test+jumps on every function call).

I rather like the implicit conversions. Especially in D where they only happen where its safe.

There's the 'to' function to perform checked conversions and the standard cast operator to perform unchecked conversions.

int foo = 256; ubyte bar = foo.to!ubyte; // throws ConvException ubyte baz = cast(ubyte) foo; // overflows as expected

If I want more type-safety than this, I'll create simple wrappers:

struct Seconds { int value; alias value this; }

That way I can still pass seconds everywhere an int is expected, but I can now declare arguments to only accept Seconds and not ints.

std.typecons.Typedef does something similar: http://dlang.org/phobos/std_typecons.html#.Typedef

> I want implicit conversion to be forbidden unconditionally

Not going to happen in a language with 11 integer types.

> (double-throw)

Exceptions are chained together.

Walter, is there any chance that we will see the source code to Digital Mars C++ release at some point? Or is it encumbered in ways that would make such a release impossible?

You can buy a copy of the source code from Digital Mars if you like. It's a bit old fashioned, though. At some point I'll probably just make it free, though it'll still have the Symantec license on it.

Reply on news.ycombinator.com