On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
> The article aims to explain how to use @safe, @system and importantly, @trusted, including all the hairy details of templates.
>
> https://jakobovrum.github.io/d/2016/01/20/memory-safety.html
>
> Any and all feedback appreciated.

Good work. Someone has to re-edit-it if not yet reeddited.

Altgough one thing, attributes are not the easy part of D. I've recently encountered a case were in the library attributes were allright, test OK, and then suddently when I've started to use the library in a real life context I had to remove them from the library...@safe was unsustainable.

Dealing with attributes is the hardest part of D IMO.
No one is forced to btw, there are plenty of other cool things in D but to follow the D safety is hard...

congrats nice article.

On Thursday, 21 January 2016 at 04:59:01 UTC, Basile B. wrote:
> On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
>> The article aims to explain how to use @safe, @system and importantly, @trusted, including all the hairy details of templates.
>>
>> https://jakobovrum.github.io/d/2016/01/20/memory-safety.html
>>
>> Any and all feedback appreciated.
>
> Good work. Someone has to re-edit-it if not yet reeddited.
>
> Altgough one thing, attributes are not the easy part of D. I've recently encountered a case were in the library attributes were allright, test OK, and then suddently when I've started to use the library in a real life context I had to remove them from the library...@safe was unsustainable.
>
> Dealing with attributes is the hardest part of D IMO.
> No one is forced to btw, there are plenty of other cool things in D but to follow the D safety is hard...
>
> congrats nice article.

I mean '@safe' at too low level is a handicap. It's like 'const'. They are hard to use, mostly because of transitivness. These attributes are never a noop.

On Thu, Jan 21, 2016 at 04:59:01AM +0000, Basile B. via Digitalmars-d-announce wrote: [...]
> Altgough one thing, attributes are not the easy part of D. I've recently encountered a case were in the library attributes were allright, test OK, and then suddently when I've started to use the library in a real life context I had to remove them from the library...@safe was unsustainable.

Phobos/druntime still has some ways to go before using it from @safe code will be painless.  Some pretty fundamental functionality still isn't @safe (mainly some stuff in object.di that basically interacts with too many other things that marking one thing as @safe will percolate throughout pretty much everything, breaking a whole bunch of stuff at once).

I once tried writing a @safe program, and it didn't take very long before I threw that idea out the window.  Once main() is @safe, you're so straitjacketed that you basically can't write anything too much more complex than Hello World.  (Well, you *could* just slap @trusted on whatever it is that's holding you back, but then that breaks the promise of @safe, which defeats the purpose of the entire exercise.)

There's also still a good number of @safe-related bugs on Bugzilla, several of which involve built-in language constructs that break @safe-ty outright. Things have improved a bit since I last checked, but it seems to me that @safe is still not quite ready to live up to its promise just yet. Maybe in a few more years' time...


> Dealing with attributes is the hardest part of D IMO.  No one is forced to btw, there are plenty of other cool things in D but to follow the D safety is hard...
[...]

I think Walter has mentioned before that attribute inference is the way to go, and I agree. Once you start writing carefully-attributed code, you'll quickly find that your declarations become painfully verbose, which is never a good sign (it encourages people not to use attributes). However, attribute inference on templates and auto functions (proposed last year, don't know if it's implemented yet) alleviates a lot of the verbosity. Hopefully the scope of attribute inference will increase until it makes attribute use more widespread in your everyday D code.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.

On Thu, Jan 21, 2016 at 05:09:48AM +0000, Basile B. via Digitalmars-d-announce wrote: [...]
> I mean '@safe' at too low level is a handicap. It's like 'const'. They are hard to use, mostly because of transitivness. These attributes are never a noop.

Transitivity also makes const really painful to use in a widespread way. I've tried writing const-correct code before too, but gave up because it quickly became too unwieldy to work with. I started spending more time hunting down missing const attributes than actually writing useful code, so I decided it was time to give up.

Generally, though, const is still useful in lower-level code (i.e., near the leaf nodes of your function call tree), to prevent silly mistakes. Knowing how to use const is also helpful in utility functions that need to accept both immutable and mutable, etc.. Just like with (the current state of) @safe, though, pervasive use of const is still too onerous currently. Transitivity really makes it painful, especially when important chunks of Phobos still isn't fully const-correct (or at least const-compatible) yet. A lot of progress has been made, but, const being transitive, all it takes is for one small Phobos function to be non-const when it should be const, and your entire call tree can no longer be const. Encounter this a handful of times, and it's hard not to just throw in the towel instead of spending all of your time working around const issues rather than writing useful code.

(Recently I'm slowly moving towards writing *all* my code as template functions, and letting the compiler do the tedious work of attributing my code instead of typing them out myself. My secret wish is that one day, the compiler's attribute inference will be good enough that I could just slap one or two const's (or @safe, etc.) on top of my modules and everything will Just Work.)


T

-- 
Only boring people get bored. -- JM

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
> The article aims to explain how to use @safe, @system and importantly, @trusted, including all the hairy details of templates.
>
> https://jakobovrum.github.io/d/2016/01/20/memory-safety.html
>
> Any and all feedback appreciated.

my experience with @safe:

okay, I'll just use @safe here... and nothing else in third party libraries/half of phobos is @safe friendly so I guess I'll wrap it in @trusted oh fuck it

On Thursday, 21 January 2016 at 06:20:01 UTC, rsw0x wrote:
> okay, I'll just use @safe here... and nothing else in third party libraries/half of phobos is @safe friendly so I guess I'll wrap it in @trusted oh fuck it

Yeah, using @trusted like that is counterproductive. Just use @system or improve the dependencies.

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
> The article aims to explain how to use @safe

Um, no, the article doesn't explain how to use @safe, it shows patterns that can be used to write safe code. The target audience must already understand safety.

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote:
> snip

Thanks for all the feedback. I've pushed a revision with further changes, most of it based on the feedback in this thread.

https://github.com/JakobOvrum/jakobovrum.github.io/commit/07c270567097f6cae5d9b95c88bd4d6c8124498c

(I'll try to remember not to force push over this commit and break the link, but if it is broken in the future, sorry, I probably slipped up and forgot.)

On Thursday, 21 January 2016 at 04:31:25 UTC, Jakob Ovrum wrote:
> That was for non-templated functions where this approach makes no sense. Indeed it is counterproductive, because @trusted on the whole function is a better indication of what needs to be reviewed for memory safety (the whole function!).

Thanks! I got confused because your used example actually leaves @safe hole with this specific usage of @trusted :

void foo(T)(T t) {
    auto p = () @trusted { return &t; } ();
    p.bar();
}

struct S { int x; }
S* global;

void bar (S* ptr) @safe
{
    global = ptr;
}

void main () @safe
{
    foo(S.init);
    global.x = 42; // oops, writing to some random stack memory
}

I'd suggest at the very least to add a comment before "p.bar();" saying "Must not escape 'p' pointer or @safe-ty will be compromised".

On Thursday, 21 January 2016 at 13:39:48 UTC, Dicebot wrote:
> I'd suggest at the very least to add a comment before "p.bar();" saying "Must not escape 'p' pointer or @safe-ty will be compromised".

I thought about this case, but it relies on UFCS which is controlled by the callee. The caller can't inject that call if the callee is careful with its imports.

For member functions, the this reference is `ref` and its address cannot be taken in @safe code.