Encapsulating trust

[Paulo Pinto via Digitalmars-d]

On Tuesday, 2 September 2014 at 09:36:50 UTC, ketmar via 
Digitalmars-d wrote:
> On Tue, 02 Sep 2014 09:24:37 +0000
> Paulo Pinto via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> And thus we end with the security exploits and computer errors 
>> C has brought into the world.
> ok, so we should disable @trusted nested functions then, 'cause
> @trusted blocks are just syntactic sugar for them. and pointers 
> --
> pointers are dangerous! and system calls -- system calls are 
> dangerous!
> and manual memory management -- manual memory management is 
> dangerous!
> and... wait, what do you mean by "D is not java"?
>
> how having handy sugar for the thing that is *already* in 
> language can
> hurt us here?

I sure like D isn't Java.

In principle sounds very nice to "thrust the programmer", but 
this only works for single coders, or teams with top level coders.

In the sad reality of every day computing tasks, the code is as 
good as the worst developer on the team.

So yes, manual memory management goes astray when such developers 
keep rotating in teams with medium size code bases.

Happy pointer chasing, like C does, leads to all sort of nice 
bugs in the same development scenarios.

Specially bad, given that the alternatives at the time, for the 
same use cases, didn't require such pointer chasing like C does.

I like quite much that D follows Ada and Modula-3 model of 
explicit system/trusted/safe code.

--
Paulo