ketmar:

> and that is why my "local D" diverges more and more from "mainline D".

This is a bad idea, it leads to an increase of your dissatisfaction, until you stop using D :-(

Bye,
bearophile

On Tue, 02 Sep 2014 08:40:35 +0000
bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > and that is why my "local D" diverges more and more from "mainline D".
> This is a bad idea, it leads to an increase of your dissatisfaction, until you stop using D :-(
no, it just leads me to being isolated ('cause "my" D still able to compile any "mainline D" code, and "mainline D" is unable to compile mine code). but "being isolated" is the thing i used to for decades.

this makes me happier too, 'cause i have a better language to write *my* code. my dissatisfaction increases when i see legacy and "anti-human" in "mainline D" which is not going to be fixed. there i have only two choises: either become more and more frustrated and drop D or fix that at least in "my D" and be happy. i chose second way.

'cause i don't want to go back to C or C++: i can't live without template magic, mixins, CTFE, UFCS and other D wonders anymore! ;-)

and i don't mind keeping my patches up-to-date: it's not hard and even fun sometimes.

On Tuesday, 2 September 2014 at 06:44:13 UTC, ketmar via Digitalmars-d wrote:
> On Mon, 01 Sep 2014 17:03:01 -0700
> Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> I also don't agree with the notion of having @trusted blocks of the
>> form:
>> 
>>      @trusted {
>>          ... system code ...
>>      }
>> 
>> We already have a mechanism to do that - @trusted nested functions.
> why don't add some sugar here? nothing will stop a dedicated person if
> he wants to write "bad code". yet making life harder for thouse who
> knows what they doing is... anti-human. this discriminating
> knowledgeable people, forcing them obey the rules that was written for
> fools. yet that rules will not stop fools of doing foolish things.
>
> lose-lose.

And thus we end with the security exploits and computer errors C has brought into the world.

On Tue, 02 Sep 2014 09:24:37 +0000
Paulo Pinto via Digitalmars-d <digitalmars-d@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?

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@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

On Tue, 02 Sep 2014 11:08:25 +0000
Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

let me ask it again:
how, in the name of hell, having handy sugar for the thing that is
*already* in the language can hurt us here?

On Tuesday, 2 September 2014 at 11:30:43 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 02 Sep 2014 11:08:25 +0000
> Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> let me ask it again:
> how, in the name of hell, having handy sugar for the thing that is
> *already* in the language can hurt us here?

In this particular case:

Because it _is_ handy. It shouldn't be. It's supposed to be ugly, to make you think twice whether you actually want to use it.

Besides, as was already mentioned, 'grep -r @trusted' wouldn't work anymore.

On Tuesday, 2 September 2014 at 08:40:37 UTC, bearophile wrote:
> ketmar:
>
>> and that is why my "local D" diverges more and more from "mainline D".
>
> This is a bad idea, it leads to an increase of your dissatisfaction, until you stop using D :-(

I am interested in ketmar's patches. Modifying the parser is a small change and you can have multiple parsers in the same compiler. Since D files start with "module " you can discriminate the source code by looking at the head of the file.

I've been sketching a modified syntax for parts of D for a while now so ketmar's work is going to make the implementation work easier for me. Thus, I applaud his rebellious efforts. :-)

On Tue, 02 Sep 2014 11:37:38 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Because it _is_ handy. It shouldn't be. It's supposed to be ugly, to make you think twice whether you actually want to use it.
where i can vote for making pointer syntax unusable too? something like
'void
yes_i_really_want_to_declare_pointer_here_secret_password_47385hjfhiegeiojewqon
________star________ p;'?

On Tue, 02 Sep 2014 11:37:38 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Because it _is_ handy. It shouldn't be. It's supposed to be ugly, to make you think twice whether you actually want to use it.
what i'm trying to say it that D either *system* language or java-like crap that tries to artificially "protect" the programmer and fails.

such king of "uglification for protection" doesn't work: it annoys people who know what are they doing and will not stop idiots anyway, 'cause idiots are very inventive in their ways of doing idiocity.