On Sunday, February 25, 2018 02:58:33 Seb via Digitalmars-d-learn wrote: > On Sunday, 25 February 2018 at 02:37:00 UTC, Jonathan M Davis > > wrote: > > If any exceptions could be thrown, then a lazy solution can't > > be @nogc (something that's often the case with strings thanks > > to auto-decoding and UTFExceptions), and a solution could be > > eager without allocating if the result doesn't require any > > allocation. > > FYI -dip1008 is a thing now and part of 2.079. > See also: > > https://dlang.org/changelog/pending.html#dip1008 > https://run.dlang.io/is/clNX6G > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
That will help eventually, but it requires a compiler flag, so it's really not going to help for code in general right now, and the fact that that DIP does nothing to solve the problem of how to create exception messages without allocating them on the GC heap means that exceptions in general are still frequently going to result in allocations unless you jump through several hoops to be able to create an exception message that's in a static array or malloc-ed or something. So, I don't know how much it's going to help in practice outside of code where the programmer is absolutely determined to have no GC allocations. > > Also, you could have a lazy range that involves a lambda that > > allocates a closure. > > Of course, or a @nogc range that allocates with malloc or eagerly > steps through the entire range. > > Anyhow I just mentioned it because it's the best form of > automatic checking that we have (what the OP was asking for) and > in many cases when an algorithm can't be @nogc it does allocate > somewhere which is a red flag. Yeah. There does tend to be a correlation between @nogc and whether a range is lazy, but it's not guaranteed, so I'm inclined to think that it's a poor idea to rely on it and that it's just ultimately better to look at the documentation or even the code. - Jonathan M Davis
