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

On Sunday, 25 February 2018 at 03:41:27 UTC, Jonathan M Davis wrote:
> On Sunday, February 25, 2018 02:58:33 Seb via Digitalmars-d-learn wrote:
>> [...]
>
> 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.
>
>> [...]
>
> 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

Hi All,

  Sorry, I am not able to see any correlation between the raised topic and the conversation that is happening in this forum, could any one please explain on of what is going on and how do you thing that this conversation is related to the topic raised, if not would suggest you to open a new topic.

From,
Vino.B

On Sunday, 25 February 2018 at 13:25:56 UTC, Vino wrote:
> On Sunday, 25 February 2018 at 03:41:27 UTC, Jonathan M Davis wrote:
>> On Sunday, February 25, 2018 02:58:33 Seb via Digitalmars-d-learn wrote:
>>> [...]
>>
>> 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.
>>
>>> [...]
>>
>> 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
>
> Hi All,
>
>   Sorry, I am not able to see any correlation between the raised topic and the conversation that is happening in this forum, could any one please explain on of what is going on and how do you thing that this conversation is related to the topic raised, if not would suggest you to open a new topic.
>
> From,
> Vino.B

I think this will work:

import std.container;
import std.algorithm;
import std.range;
import std.stdio;

void main () {
auto a = Array!string("Test1", "Test2", "Test3", "Test1", "Test2");
auto b = Array!string("Test1", "Test2", "Test3");
foreach(i; b[])
  a[].enumerate.filter!(a => a[1] == i).map!(a => a[0]).SList!size_t[].writeln;