D Article: Memory Safety

[H. S. Teoh via Digitalmars-d-announce]

On Thu, Jan 21, 2016 at 04:38:08AM +0000, Jakob Ovrum via Digitalmars-d-announce wrote:
> On Wednesday, 20 January 2016 at 15:28:05 UTC, jmh530 wrote:
> >I like the description of @trusted and template inference. Template
> >inference, in particular, was not something that was obvious to me
> >when first reading about D. I'm not sure how clear you make it that
> >you can still mark templates @safe and what have you (you seem to
> >just say don't make templates @trusted).
> 
> Templated functions can still be explicitly annotated with attributes,
> which disables inference for those attributes. This is often a good
> idea even for templated functions when template arguments do not
> inject code, so that every instantiation has the same, known set of
> attributes. Attribute inference can handle it, but explicit
> annotations provide documentation value. I might incorporate this into
> the article, but I'm wary of it losing focus.

A common idiom used in Phobos related to this is to use an attributed
(pure, nothrow, @nogc, etc.) unittest that instantiates the template in
question, to ensure that it does not accidentally become non-pure,
throwing, etc. (the unittest will stop compiling if so). This way, we
ensure that the template itself doesn't contain any impure / throwing /
@system code, even though you can instantiate it with template
parameters that may be impure, throwing, @system, etc..


> >I wasn't aware of the point that "@trusted nested functions in
> >templated functions do not have to have a memory safe interface as
> >long as all calls to the function are memory safe". Interesting.
> 
> It is a necessary evil to propagate attributes correctly. Don't use it
> when you don't have to.

Wouldn't it be better to refactor the code to separate out the part that
needs to be @trusted into a separate place, with a safe API? Or are
there cases for which this is impossible?


T

-- 
The early bird gets the worm. Moral: ewww...