On Tuesday, 2 September 2014 at 11:55:58 UTC, ketmar via Digitalmars-d wrote:
> 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.

For some strange reason human life critical systems are written in Ada, SPARK, MISRA C dialect

On Tuesday, 2 September 2014 at 08:24:42 UTC, ketmar via Digitalmars-d wrote:
> please note that i'm not trying to say that D developers doing
> everything wrong nor that they are incompetent. D is great. but we can
> make it even better. just stop buying "enterprise need stability" bs:
> we have enough "enterprise-stable" languages already, let's make one
> that is attractive to programmers.

I am by all means regular advocate of changes but your are pushing it to other radically harmful attitude. There is a huge difference between maintaining own set of patches that work for cases you personally use language for and maintaining feature constantly in the publicly available upstream. Things break in most unexpected ways when exposes to even small / medium user bases, we have it all the time.

For example, this specific syntax is absolutely guaranteed to result in weird issues because it is ambiguous with already existing one (that applies attributes to declarations). In the end it gives you _nothing_. Saving two characters for already short idiom that is not even supposed to be easy to use is just a joke. There is simply no way something as trivial as that is going to pull its weight.

There is a limited amount of maintenance effort we can invest into adding new stuff to language and it needs to be used wisely.

On Tue, 02 Sep 2014 13:15:01 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> For example, this specific syntax is absolutely guaranteed to result in weird issues because it is ambiguous with already existing one (that applies attributes to declarations).
please write a sample. i'm not trying to troll, i really don't understand what you mean here. you can't have '@nothrow' and '@pure' UDAs anyway.

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

> For some strange reason human life critical systems are written in Ada, SPARK, MISRA C dialect
ah, sorry, i was thinking that this is NG for D language... mea culpa.

Paulo Pinto:

> For some strange reason human life critical systems are written in Ada, SPARK, MISRA C dialect

If D designers and developers work to make D better for those usages, someday D could be used to replace the MISRA C and perhaps even some less strict usages of Ada.

Bye,
bearophile

On Tuesday, 2 September 2014 at 13:42:05 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 02 Sep 2014 12:18:08 +0000
> Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> For some strange reason human life critical systems are written in Ada, SPARK, MISRA C dialect
> ah, sorry, i was thinking that this is NG for D language... mea culpa.

And I though we were all grown ups and not school kids, looking at the level of your posts to other members.

Stepping out of this discussion.

02-Sep-2014 04:03, Walter Bright пишет:
> On 8/31/2014 6:47 AM, Dmitry Olshansky wrote:
>> import core.stdc.string;
>> import trusted;
>>
>> void main() @safe
>> {
>>
>>      char[] msg = "Hello!".dup;
>>      char[] msg2 = msg;
>>      import trusted; // may also use static import for absolute clarity
>>      assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length)
>> == 0);
>> }
>
> I don't agree with the notion of having primitives that provide escapes
> from @safe - it means the interleaving of @safe and @system code becomes
> too easy, and too easy to miss.
>

Make distinctive name like assumeSafe and it's going to be trivially grepable.

> 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. The
> code example becomes:

So there is need, but somehow requires a bunch of useless boilerplate, like repeating arguments and inventing creative names for local functions.
>
>    void main() @safe {
>       char[] msg = "Hello!".dup;
>       char[] msg2 = msg;
>
>       void checkEquals(const char[] msg, const char[] msg2) pure @trusted {
>         assert(msg.length == msg2.length);
>         assert(memcmp(msg.ptr, msg2.ptr, msg.length) == 0);
>       }
>

So you think adding boilerplate will make function more easily verifiable? Time and statistics proven that more LOCs ==> more bugs. Especially highly repetitive patterns, because nobody actually reads them.



-- 
Dmitry Olshansky

02-Sep-2014 15:37, "Marc Schütz" <schuetzm@gmx.net>" пишет:
> 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.

Making things ugly doesn't make them safe or easier to verify.
Somehow people expect the opposite, but just take a look at e.g. OpenSSL :)

Slapping @trusted across whole functions just blurs the scope of system code (where? what was system? or maybe it's that pointer ... it's really hard to analyze afterwards).

-- 
Dmitry Olshansky

01-Sep-2014 20:36, Daniel Murphy пишет:
> "Dmitry Olshansky"  wrote in message news:ltv91u$2mtc$1@digitalmars.com...
>
>> Quite recently a lot of work has been done to make most of Phobos
>> usable in @safe code.
>>
>> While a very welcome effort, it caused a number of doubts in
>> particular due to the boilerplate required to isolate a small amount
>> of unsafe operations and slap "@trusted" over it.
>>
>> See e.g. Denis argument:
>> https://github.com/D-Programming-Language/phobos/pull/2465
>>
>> There were proposals for language changes along the lines of having
>> @trusted block alike to debug/version blocks, but nothing ever came
>> out of them.
>>
>> Without language support I decided it worth a shot to create a
>> universal wrappers to establish a consistent convention. A use of such
>> wrapper should indicate that a @system function call or language
>> feature was hand-verified.
>>
>
>>
>> What do you guys think?
>
> I think this is an abuse of @trusted.  It takes unsafe operations, and
> re-presents them as @safe options by renaming them.  Now, you can do use
> @system things in @safe functions without the compiler detecting it.
>
> Take the `addrOf` function for example.  This is equivalent to adding a
> new version of the '&' operation, which does exactly the same thing
> except it's allowed in @safe code.  The `addrOf` function should _not_
> be @trusted, because when used from @safe code it can cause escape the
> address of a local etc, just like '&' can.

>
> Because these functions violate the meaning of @trusted, that @trusted
> functions must be @safe although the compiler can't prove them @safe,
> you've increased the surface of @trusted.  Now an audit of @trusted code
> must include all functions that call `addrOf` and friends.
>

Only these that import stdx.trusted. Trivial to check.

> I don't think this is a good idea.  Each time @trusted is used, it
> should be on a function that is completely @safe to call.  I think this
> is worth more than the cost in verbosity.

I'd be damned but it's made precisely because taking address is frequently needed in a function that is otherwise @safe. Alternative of marking the whole thing as @trusted ain't going in the right direction.

Instead of writing the same ugly shit (pardon local functions and lambda+call) everywhere, let just compose a set of markers (2-3 functions) that indicate something as trusted block.

Obviously one can easily abuse it, much like @trusted can be easily abuse today, especially with templates where it's easy to fail in trap of putting @trusted on the whole function and trust pretty much any 3rd party type to be safe.

>
> Lambdas and nested functions are special in that they can't be called
> from other code, so they only have to be @safe in the context of the
> enclosing function.  They do still need to make sure they don't violate
> @safe, otherwise the entire enclosing function will need to be manually
> checked.

They have in common is lot of noise that distracts and obfuscates the thing that already needs our full attention making it both bigger and harder to follow.

> eg
> void fun(int a) @safe
> {
> ...
>     p = @trusted () { return &a; }
> ...
> }
>
> This function is now essentially @trusted, because although the unsafe
> '&' operation was inside the trusted block, the @safe function now has a
> pointer it should not have been able to get.

Careful there - a trusted lambda must ensure that pointer is fine, although the means of getting it are @system. The same review-driven thing about @trusted remains.

-- 
Dmitry Olshansky

31-Aug-2014 17:47, Dmitry Olshansky пишет:
> Quite recently a lot of work has been done to make most of Phobos usable
> in @safe code.
...
>
> What do you guys think?
>

Probably a lot of people missed the point that if we standardize a few idioms (dangerous but at least centralized) we at least can conveniently contain the "abuse" of @trusted to the select standard module. Else it *will* be abused in a multitude of ways anyway.

-- 
Dmitry Olshansky