New slides about Go

[bearophile]

Nick Sabalausky:

> Then you're wasting cycles every iteration (by doing an extra addition and 
> maybe an extra shift or even multiplication depending on T: Ie, 
> (cast(ubyte*)myArray.ptr) + i * T.sizeof). That was a pretty common 
> inner-loop optimization back in my C days.

With D sometimes array-based code is faster than pointer-based. With LDC they are usually equally efficient.


> Plus, I've never once done pointer arithmetic accidentally in D, so I don't 
> see any safety to be gained from not allowing it.

I think they are trying to design a safer language. Pointer arithmetic is well known to be error-prone.
(I have never asked to remove pointer arithmetic from D).


> > - Turning x++; into statements seems harsh, but indeed it solves some 
> > problems. In practice in my D programs the ++ is often used as a 
> > statement, to avoid bugs.
> 
> I've long been of the opinion that should just be a statement. All it ever 
> does as an expression, if anything, is obfuscate code. I've never once seen 
> a case where it clarified anything.

In some cases it shortens the code a bit, but the price to pay for such shortening is some possible bugs.

I think/hope D will turn the sub-expression deterministic, so some expressions that contain ++ and function calls will be defined in D:

Bye,
bearophile