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