On Tuesday, 2 September 2014 at 14:10:39 UTC, Dmitry Olshansky wrote:
> 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:
>>> 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).

I agree, it needs to be as fine-grained as possible. I just happen to believe that the suggested template wrappers are not a good idea.

Note that my post was in response to the question how "having handy sugar [...] can hurt us here". That doesn't automatically mean that the alternatives are perfect.

On Tuesday, 2 September 2014 at 14:33:53 UTC, Dmitry Olshansky wrote:
> 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.

I think it's probably hard to appreciate where you are coming from, until you've reviewed code for things such as Appender and/or emplace. I swear there was 1 point where roughly 25% of the lines of code in that thing where wrapped in a trusted lambda.

1 issue I find with your proposal, is (personally), I've seldom had to *call* unsafe functions in a trusted fashion, but rather, had to do unsafe *things*:

if (capacity > slice.length)
    slice = @trusted(){return slice.ptr[0 .. slice.length + 1];}();

In such context, "call!" wouldn't help much. That said, there are also plenty of cases where we call memcpy (just grep "trustedMemcpy" in phobos), where your proposal would help.

Also: There's already a help "addressOf" somewhere in phobos. It's meant mostly to take the address of property return values. Instead of providing "addressOf" in std.trusted, you could simply do a "call!" of the not-trusted generic "addressOf". Just a thought.

On Tuesday, 2 September 2014 at 13:15:02 UTC, Dicebot wrote:
> 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.

Something I'm feeling as a newcomer to D reading these threads, is that the community has already thought of a number of guidelines for Phobos development, but they are buried in the forum. I also saw one which is controversial - the idea that embedded systems programmers should be able to use some subset of Phobos without bloating their executable. I'd have no idea whether we are trying to maintain that property of Phobos where it already exists, or ignore it. Similarly, there are a lot of diverse goals/use cases people have in mind - the std.logger thread has some.

It feels like Phobos has a good amount of 'breadth'' but could do with more "depth". Have we already tried some exercises which would flesh out more "Phobos requirements" (I.e. That we aspire to for existing modules and require for new ones?)

"Dmitry Olshansky"  wrote in message news:lu4j4v$leu$1@digitalmars.com...

> 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 :)

No, but making unsafe code ugly makes the safe alternatives look more attractive, and hopefully more likely to be used.  It also makes the unsafe code stand out more, so it is less likely to be overlooked.

> 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).

Nobody is suggesting this. 

"Dmitry Olshansky"  wrote in message news:lu4jld$m0b$1@digitalmars.com...

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

Sure, if this type of function only exists in that module (and there are no public imports of it).  But you've still made it so you now have to inspect @safe functions for non-@safe code.

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

Of course marking the whole thing as @trusted is wrong.

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

If you're writing a lambda to take the address of a variable, then you're using @trusted wrong.  Neither should be done.

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

That's what we have code review for.

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

Yes, they are noisy.  But that noise does make them stand out more.

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

A trusted lambda must give the same guarantees any other @safe of @trusted function gives - that when called from inside a @safe function it will not violate memory safety with any possible arguments.

I'm not saying that you should mark entire functions as @trusted because parts of them are not @safe.  You should instead extract the unsafe parts into a nested function or lambda (or external function) that provides a completely @safe interface.

This way the _only_ code than needs @safeness review is inside functions marked as @trusted. 

"Dmitry Olshansky"  wrote in message news:lu4iup$l9v$1@digitalmars.com...
> >
> >    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.

Yes, that function is more easily verifiable for @safety, because any violation _must_ be inside the @trusted function.  If the @safe violating helpers were used, main would effectively be @trusted and more lines would need to be reviewed.

> Especially highly repetitive patterns, because nobody actually reads them.

If you have highly repetitive patterns, they should be factored out into reusable functions just like always. 

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).
ah, you talking about `@trusted { ... }`, right? why it is ambiguous? i applied one restriction to it: @trusted block must always be "{}"-blocks. that removes ambiguity altogether.

it's not about saving some chars, it's about not writing arcane constructs like:

  () @trusted {
    ...
  }();

this looks weird.

but hell with that "trusted blocks", how about foreach i mentioned?
not accepting 'auto' in `foreach (auto i; 0..42)` is just illogical.
here we saving 5 chars for... for what? `foreach (i; 0..42)` looks
exactly like `for (i = 0; i < 42; ++i)`, yet it means something
completely different.

i understand that we can't make 'auto' mandatory there, but why don't make it at least acceptable? (and then add a deprecation warning, and then finally make 'auto' mandatory)

as the time passing it becomes increasingly hard to fix this "cosmetic issues", as there are more and more people writing D code. i don't believe that waiting for another year or three and then just saying "alas, this train is gone long ago so now we must live with this legacy" is a good solution.

yes, i'm relatively new in D world and my position may look like extremist one, but all i want is to make D better. that's why i'm writing those posts instead of sitting silently in my shell. i know that we can't change C or C++, but i believe that we can change D. not by throwing in random features, but by making D more consistent, better looking and more pleasant to use.

"Dmitry Olshansky"  wrote in message news:lu4kgh$mpm$1@digitalmars.com...

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

> we at least can conveniently contain the "abuse" of @trusted to the select standard module

This is Wrong!  Any function that uses these wrappers is abusing @trusted.

eg:

import stdx.trusted;

int* func(int x) @safe
{
   return addrOf(x);
}

This functions is @safe, but happily returns an invalid pointer.  This is possible because addrOf violates the requirement that @trusted functions must be completely @safe to call from an @safe function.

Say we have a very useful function like this:

void doThing(bool corruptRandomMemory) @system { ... }

So if the parameter is true, it will cause memory corruption, otherwise it will not do anything that violates @safe.

This is a valid @trusted wrapper:

void doThingTrusted() @trusted { doThing(false); }

This is not:

void doThingTrusted(bool b) @trusted { doThing(b); }

Having syntax (or a wrapper function) to do the second wrapping automatically would violate @safe.  If it was syntax, it would be banned in @safe.  If it's a wrapping method like the proposed 'call', then it is a program error for it to be marked @trusted. 

On Tuesday, 2 September 2014 at 17:20:06 UTC, Daniel Murphy wrote:
> This is Wrong!  Any function that uses these wrappers is abusing @trusted.
>
> eg:
>
> import stdx.trusted;
>
> int* func(int x) @safe
> {
>    return addrOf(x);
> }
>
> This functions is @safe, but happily returns an invalid pointer.  This is possible because addrOf violates the requirement that @trusted functions must be completely @safe to call from an @safe function.

That's a good point.

> Having syntax (or a wrapper function) to do the second wrapping automatically would violate @safe.  If it was syntax, it would be banned in @safe. If it's a wrapping method like the proposed 'call', then it is a program error for it to be marked @trusted.

Good points too.

A very logical conclusion.

On 9/2/2014 10:20 AM, Daniel Murphy wrote:
> Having syntax (or a wrapper function) to do the second wrapping automatically
> would violate @safe.  If it was syntax, it would be banned in @safe.  If it's a
> wrapping method like the proposed 'call', then it is a program error for it to
> be marked @trusted.

I agree with monarch_data, this is the executive summary, the salient point, the money shot, etc.