"monarch_dodra"  wrote in message news:wvslfmdauwupzioryhgq@forum.dlang.org...

> I meant it mostly in that the proposal to mark the entire function as @trusted isn't even *applicable* to template functions.

That isn't what I was proposing.  Using a trusted nested or lambda function is fine, but it should not be possible to violate @safe by changing only the enclosing function.

eg making a trustedMemcpy is just as much a violation of @safe as marking the actual memcpy as @safe.  It still relies on the calling function being manually verified not to call it incorrectly.  If your calling function needs to be manually verified, it should be @trusted.  If it can't be manually verified, it should be @system. 

On Monday, 1 September 2014 at 18:29:32 UTC, Daniel Murphy wrote:
> "monarch_dodra"  wrote in message news:wvslfmdauwupzioryhgq@forum.dlang.org...
>
>> I meant it mostly in that the proposal to mark the entire function as @trusted isn't even *applicable* to template functions.
>
> That isn't what I was proposing.  Using a trusted nested or lambda function is fine, but it should not be possible to violate @safe by changing only the enclosing function.
>
> eg making a trustedMemcpy is just as much a violation of @safe as marking the actual memcpy as @safe.  It still relies on the calling function being manually verified not to call it incorrectly.  If your calling function needs to be manually verified, it should be @trusted.  If it can't be manually verified, it should be @system.

Idea is that you move not only actual unsafe operation into @trusted lambda but also any additional context that makes it effectively @safe, separating it from the rest of the function.

It is not that trivial to spot though so some mistakes are inevitable.

"Dicebot"  wrote in message news:uwalapqtroynalabxtwo@forum.dlang.org... 

> Idea is that you move not only actual unsafe operation into @trusted lambda but also any additional context that makes it effectively @safe, separating it from the rest of the function.
> 
> It is not that trivial to spot though so some mistakes are inevitable.

Absolutely.  This thread's proposal is a complete departure from that idea.

31.08.2014 17:47, Dmitry Olshansky пишет:
> 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.
>
> Names and complete set of primitives are up for debate, but here is the
> start:
>
> https://gist.github.com/DmitryOlshansky/bc02f369c8a63818bd07
>
> A bit of usage:
>
> 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);
> }
>
>
> What do you guys think?
>

The language works fine for me as it is in this aspect. E.g. functions from `std.file` like `read` should be marked as `@trusted` because this is what `@trusted` is for, a function operating unsafe stuff and providing a safe interface to it.

Currently the only problem is with templates like `std.array.Appender` when we want the compiler to infer attributes from user type and have to carefully wrap our code in `@trusted` blocks leaving calls to user code unwrapped.

Yes, my opinion here is the same as Daniel's one.


About related `std.file` pulls:

I wrote my original comment [1] to the pull because it blows the code size and reduce its readability by using `@trusted` nested functions (lambdas not used just because they currently can't be inlined, but it's silly as these functions work with disk and thus slow anyway).

This introduces a bad anti-pattern in the library and should be reverted. Just imagine a D newbie who just started leaning the language and is reading `std.file` module to see how easy can he use native API in D (e.g. I was such newbie). With all these pulls merged (current HEAD) he will be terrified of the code ugliness and either decide this is the only way to use native API in D (wrap every native function in `@trusted` nested function in `@safe` function) or will spend significant time discovering the history of this module and who is guilty in such bad design (e.g. I spend a lot of time when learned D because of `TypeTuple` used with expressions which completely confused me).


[1] https://github.com/D-Programming-Language/phobos/pull/2465#issuecomment-53950146

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

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.

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:

  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);
     }

     checkEquals(msg, msg2);
  }

Granted, this can be abused to subvert the @safe/@trusted/@system system, but that has always been the case. Note that I added an assert to make checkEquals() actually trustworthy. The QA code reviewer can still grep for @trusted and flag them for special review.

These sorts of nested functions should inline and pose no extra overhead.

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.

On Tuesday, 2 September 2014 at 06:44:13 UTC, ketmar via Digitalmars-d wrote:
> 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.

Because by adding dedicated syntax you save 2 (two!) symbols and gain nothing else. And get all the associated compiler maintenance costs which add up with each smallest feature. Not worth it.

On Tue, 02 Sep 2014 07:03:05 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Because by adding dedicated syntax you save 2 (two!) symbols and gain nothing else.
except code readability. anti-human tendencies.

> And get all the associated compiler maintenance costs which add up with each smallest feature.
so let's stop adding features at all. and extending Phobos too. we are so scared by adding even simple things.

bwah, i can write that patch in a hour, and it will require very little maintenance: it will break when lambdas break, and that is not often (and such changes breaks alot of other things anyway).

p.s. sure i'll not write it, 'cause i'm not ready to fork D and my site with "D powerpatches" aren't up yet. ;-)

On Tuesday, 2 September 2014 at 07:41:25 UTC, ketmar via Digitalmars-d wrote:
>> And get all the associated compiler maintenance costs which add up with each smallest feature.
> so let's stop adding features at all. and extending Phobos too. we are
> so scared by adding even simple things.

This is what we generally do. Features get added only if they enable something fundamentally new that can't be reasonably workarounded in Phobos (which does not have such cumulative maintenance implications). This is rather strict policy.

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

> This is rather strict policy.
and that is why my "local D" diverges more and more from "mainline D". 'cause i know where to download C++ compiler if i want language which not trying to make my life easier.

one of the main things that dragged me to D was "made by humans for humans". and now D tries to wear C++ anti-human shoes -- exactly what i wanted to avoid by "migrating to D".

D is far superior to C++, but D starting to make C++ mistakes. not
fixing legacy syntax, not adding new handy features, abusing keywords
(enum constants anyone? why 'enum'?! ah, 'const' is already taken)...
`foreach (auto i; 0..42)`? no-no-no! it worth nothing that newcomers
will be surprised by `foreach (i; 0..42)`, asking "where that 'i'
variable was declared?" and that 'auto' is an ideal candidate here,
as 'type placeholder for variable declaration'. nameless args for
"foreach"? no-no-no, you can't write `foreach (int, string; smth)` --
invent silly names for unused args. `foreach (; 0..42)`? heretics!
nobody will understand that arcane operator! allowing '@' before 'pure'
and 'nothrow'? no-no-no, we can't declare D mature without legacy! and
so on...

ah, and "foreach_reverse" abomination... i don't even want to talk about this *keyword*.

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.