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