On 12/24/2017 7:00 AM, Dylan Graham wrote:
> I also recall someone saying that C++'s memory problem is fixed. D's MMM seems infantile in comparison.

Only if someone considers this as fixed:

    int foo(int* p) { return p[1]; }
    int bar(int i) { return foo(&i); }

    clang++ -c test.cpp -Wall


and this as infantile:

    @safe:
    int foo(int* p) { return p[1]; }
    int bar(int i) {return foo(&i); }

    dmd -c test.d
    test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
    test.d(4): Error: cannot take address of parameter i in @safe function bar

On 12/24/2017 8:51 AM, Patrick Schluter wrote:
> I ported 1 app from Java to D. It was so unspectacular (or better said it was spectacularly easy) that you're probably right. Reaching to Java devs is a good idea. The advantage of Java though, is not the language but the huge, huge, huge existing libraries and packages and know how. This will be difficult to overcome  for any language.

Yup. It's the library that makes Java, not the language. This makes it pretty hard to attract Java devs.

On 12/24/2017 9:13 AM, Laeeth Isharc wrote:
> New things grow at the fringes.  See the work of Clayton Christensen and his book the Innovator's Dilemma.  A head-on assault is ill-advised.  People looking for salvation are easier to talk to than those who don't see anything wrong with what they're doing currently.

Yes, great book! That's the purpose of -betterC. Going after the fringes.

On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright wrote:
>
> Only if someone considers this as fixed:
>
>     int foo(int* p) { return p[1]; }
>     int bar(int i) { return foo(&i); }
>
>     clang++ -c test.cpp -Wall
>
>

good example..and it makes a good point.

however, let that point be not that C/C++ is flawed (since pointers are meant to let you point to anywhere), but rather that the code example is flawed.

there is a difference between a flawed language, and flawed use of that language.

e.g. what if I accidently left out the @safe attribute on those functions in D?

On Tuesday, 26 December 2017 at 07:01:16 UTC, codephantom wrote:
> On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright wrote:
>>
>> Only if someone considers this as fixed:
>>
>>     int foo(int* p) { return p[1]; }
>>     int bar(int i) { return foo(&i); }
>>
>>     clang++ -c test.cpp -Wall
>>
>>
>
> good example..and it makes a good point.
>
> however, let that point be not that C/C++ is flawed (since pointers are meant to let you point to anywhere), but rather that the code example is flawed.
>
> there is a difference between a flawed language, and flawed use of that language.
>
> e.g. what if I accidently left out the @safe attribute on those functions in D?

Then whoever is using your code (you?) will find that out when they call your functions from a @safe function.

On Monday, 25 December 2017 at 10:20:44 UTC, Russel Winder wrote:

>
> One persons opinion is irrelevant, unless you believe in advocacy research.
>

I believe in it in the sense that it can be used to stir powerful social forces to serve propaganda. No language should be without propaganda, since adoption will most likely be more modulated by social factors instead of technical excellence.

On Tuesday, 26 December 2017 at 07:33:18 UTC, Mark wrote:
>
> Then whoever is using your code (you?) will find that out when they call your functions from a @safe function.

And if they forget to annotate their so called 'safe' function with @safe...what happens then?

Comparing the 'memory safety' of languages seems a little pointless to me..because any programmer can stuff up in any language.

As it stands, D does not nullify the truth of that statement.

Which makes me wonder why it is, that @safe is not default in D, and Phobos for that matter?

If it were, then that would be a more useful thing to promote D, because, as it currently stands, if I forget to annotate my function with @safe, then I'm in the same world of forgetting to do something in C..or C++.. or whatever...(like checking whether I'm referencing a valid memory address).

On Tuesday, 26 December 2017 at 07:01:16 UTC, codephantom wrote:
> On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright wrote:
>>
>> Only if someone considers this as fixed:
>>
>>     int foo(int* p) { return p[1]; }
>>     int bar(int i) { return foo(&i); }
>>
>>     clang++ -c test.cpp -Wall
>>
>>
>
> good example..and it makes a good point.
>
> however, let that point be not that C/C++ is flawed (since pointers are meant to let you point to anywhere), but rather that the code example is flawed.
>
> there is a difference between a flawed language, and flawed use of that language.
>
> e.g. what if I accidently left out the @safe attribute on those functions in D?

The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase.

The whole point of Walter argumentation is 'mechanically'.

/Paolo

On Tuesday, 26 December 2017 at 09:03:31 UTC, Paolo Invernizzi wrote:
>
> The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase.
>
> The whole point of Walter argumentation is 'mechanically'.
>
> /Paolo

My C/C++ code can be 'mechanically' checked too.. and those checks are better than they've even been, and getting better.

btw. I'm not arguing against the point Walter made in his reponse. Rather I'm just trying to point out that anyone saying that D is inherently safe, is wrong.

D provides a great deal of flexibility, and increasingly so, and, flexibility breeds bugs!

(don't get me wrong, I like D precisely because of this flexibilty).

But if I come with the mindset of 'safety first' (which i don't - but lets say I did), then D has some interesting surprises in store for me - the most obvious of which, is @safe is not default.

On Tuesday, 26 December 2017 at 09:21:20 UTC, codephantom wrote:
> On Tuesday, 26 December 2017 at 09:03:31 UTC, Paolo Invernizzi wrote:
>>
>> The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase.
>>
>> The whole point of Walter argumentation is 'mechanically'.
>>
>> /Paolo
>
> My C/C++ code can be 'mechanically' checked too.. and those checks are better than they've even been, and getting better.

IMHO, the lost list of vulnerability in code shipped by "first class enterprises" is just crying out that C/C++ is not mechanically checkable.
And we are talking about company that can literally spend an Everest of money on that.

/Paolo