Programming Language for Games, part 3

[bearophile via Digitalmars-d]

Walter Bright:

> D has writefln which does not have printf's issues. There's no 
> reason to add a feature for printf.

The feature we are talking about is not just for D writeln, as 
I've tried to explain several times.

And D writeln is not verified at compile-time, this is silly for 
a language that tries to be reliable. (Rust printing function is 
actually a macro and it verifies the formatting string at 
compile-time when possible. That's the only good enough option 
for me for a modern statically compiled language).


> When I look at my code,

As the designer of the language you have to look at code written 
by other people too! Because your D code is probably very 
different from mine. Take a look at Haskell code, Rust code, 
Erlang code, and learn new idioms and new paradigms. In the long 
run this will help D more than fixing a couple more bugs.


> it is very rare that I pass arguments to functions that would 
> benefit from compile time checking.

To me this happens. It doesn't happen all the time. As usual it's 
not easy to quantify the frequency of such cases. (On the other 
hand your "very rare" is unsupported by statistical evidence as 
well. Your judgement is probably better than mine, of course and 
I respect your opinions).


> For those that might, there's always a rethinking of the
> feature, such as with printf/writefln.

I regard D writefln as currently _broken_. D has static typing, 
templates and compile time execution, and yet such things are not 
used enough in one of the most common functions, the one to print 
on the console. Now even GCC catches many of those printf usage 
bugs at compile-time.

The desire for some compile-time enforcement of some contracts is 
not replaced by rethinking.

Bye,
bearophile